<div dir="ltr">Hi,<div><br></div><div>from the point of view of portability, having a split GUI and backend should be nicely portable. Even focusing on systemd would cover large portion of Linux distributions, but you don't have to include any systemd dependencies as such. On desktop, it would allow you to move the backend into dedicated hardware, if you wish. Also, it would survive X11 crashes as a bonus. So, if you plan to run it 24x7, service running on the background is a good way of doing it.</div><div><br></div><div>But maybe someone has better idea.</div><div><br></div><div>Cheers,</div><div><br></div><div>Rinigus</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 17, 2018 at 9:16 PM, Marcin Mielniczuk <span dir="ltr"><<a href="mailto:marmistrzmar@gmail.com" target="_blank">marmistrzmar@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <p>I'm not sure if that's a good choice when trying to achieve
      portability. Usually on desktop you'd rather have a monolithic
      application with just minimize to tray.</p>
    <p>Any other options?<br>
    </p><div><div class="h5">
    <br>
    <div class="m_-5396081271493200703moz-cite-prefix">On 05.02.2018 10:33, rinigus wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Hi,
        <div><br>
        </div>
        <div>the obvious solution is to run service that is 24/7 on and
          separate client for GUI. That's what stock messaging is doing.
          I would recommend it and use some simple messaging API for
          communicating between them. There are probably many APIs to
          choose that will allow you to set it up simply.</div>
        <div><br>
        </div>
        <div>If you can withstand short shutdown of the service then you
          can combine it into the same application. It would require
          that application will start in GUI or server mode depending on
          command line option. If started in GUI mode, you would have
          to </div>
        <div><br>
        </div>
        <div>* shut down service via systemd</div>
        <div>* establish new connections</div>
        <div><br>
        </div>
        <div>and on GUI exit you would have to </div>
        <div><br>
        </div>
        <div>* drop all connections</div>
        <div>* start service via systemd</div>
        <div><br>
        </div>
        <div>The latter is the way OSM Scout Server works with the
          adjustment that its using systemd sockets to keep it switched
          off when user is not accessing it. Note that it was done for
          historical reasons (signaling between parts was implemented
          via Qt) and since its mostly used as a service anyway (users
          don't need to access GUI for weeks).</div>
        <div><br>
        </div>
        <div>I would still recommend splitting service/GUI parts and use
          some messaging protocol in between. Myself I would have used
          zeromq, but you could choose probably many others.</div>
        <div><br>
        </div>
        <div>Cheers,</div>
        <div><br>
        </div>
        <div>Rinigus</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Mon, Feb 5, 2018 at 11:17 AM, Marcin
          Mielniczuk <span dir="ltr"><<a href="mailto:marmistrzmar@gmail.com" target="_blank">marmistrzmar@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
            <br>
            When creating SFOS applications which should run 24/7 (e.g.
            IMs) we<br>
            would like to achieve similar behavior as the stock
            applications, e.g.<br>
            the stock e-mail client: the sync (*) runs in the
            background, even<br>
            though the application is closed. A window staying open just
            to make<br>
            sure the sync goes on clutters the open app view and makes
            it more<br>
            difficult to manage the open applications.<br>
            <br>
            On a desktop DE one would simply minimize the application to
            tray.<br>
            Alternatively, one could create a daemon which the client
            app would<br>
            communicate with using UNIX sockets, but it greatly
            increases the<br>
            complexity of the application and slows down the
            development.<br>
            <br>
            What's the easiest way to keep the sync process in the
            background<br>
            without keeping the window open?<br>
            <br>
            Regards,<br>
            Marcin<br>
            <br>
            (*) when speaking sync, I mean any kind of waiting for a
            remote event,<br>
            no matter if it's done by idle TCP (which is good) or HTTP
            polling<br>
            (which is not good)<br>
            <br>
            <br>
            ______________________________<wbr>_________________<br>
            SailfishOS.org Devel mailing list<br>
            To unsubscribe, please send a mail to <a href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.sailfi<wbr>shos.org</a></blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="m_-5396081271493200703mimeAttachmentHeader"></fieldset>
      <br>
      <pre>______________________________<wbr>_________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to <a class="m_-5396081271493200703moz-txt-link-abbreviated" href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank">devel-unsubscribe@lists.<wbr>sailfishos.org</a></pre>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div>