<p dir="ltr">I think it is nice to start kdeconnect on demand (via dbus calls). I see the benefits of killing it automatically if there are no devices reachable, or none of them is paired, but this causes a problem: we wont be discoverable since the process is not there anymore.</p>

<p dir="ltr">I believe that Alex's solution would be to have a "placeholder" daemon only listening for connections to spawn the main process, but anyway i dont think it is worth the work just to have a (smaller?) process loaded.</p>

<p dir="ltr">Anyway we have to think a way to use ZERO memory if the user is not using kdeconnect at all, because our process now is quite fat.</p>
<div class="gmail_quote">On Mar 5, 2014 5:49 PM, "Àlex Fiestas" <<a href="mailto:afiestas@kde.org">afiestas@kde.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tuesday 04 March 2014 13:02:57 Yuri Samoilenko wrote:<br>
> I think kdeconnect must operate like any linux/UNIX service(/etc/init.d/*<br>
> as example). Exception is in that /etc/init.d/* is system services,<br>
> required root access to manage them, but kdeconnect is user service. The<br>
> option that users can do is:<br>
> 1. start/stop service<br>
> 2. autostart service when login<br>
I don't see why anybody would care on restarting/starting/stopping kde-<br>
connect.<br>
It is something build in into your KDE session, if you don't want it just kill<br>
it, no?<br>
We should use almost no cpu/ram when idle anyway.<br>
<br>
> I look on KDED as on simple service manager with user interface fits<br>
> options above. Starting-on-deman is unnecessary(for kdeconnect) facility.<br>
><br>
> >> Also, kdeconnect should be smart enough to kill itself if there is<br>
><br>
> nothing to<br>
> Hmm, no. kdeconnect daemon must running all the time to plug current<br>
> device(desktop too) into kdeconnect-network. For example I need to share<br>
> info not only with my phone(with android) but with my notebook(with<br>
> kubuntu+kdeconnect aboard). So daemons must be running on desktop and<br>
> notebook all the time.<br>
><br>
><br>
> Sorry for possible misunderstanding of you mail.<br>
KDED modules are thought so we can put there logic that will be IDLE most of<br>
the times but we still need to have it running all the time. Thing for example<br>
of receiving files via Bluetooth, we need to be listening for "incoming files"<br>
all the time but we do not really need a new process just to do that.<br>
<br>
Translated to how we could use it on kde-connect, it would be perfect for the<br>
use case of "We need to listen for new devices all the time". So KDED would:<br>
-Emit broadcast messages<br>
-Listen for broadcast messages<br>
<br>
The moment somebody wants to actually talk with us, we fire up kde-connect and<br>
let it do the heavy lifting work.<br>
<br>
When no clients are connected, then kde-connect dies, and KDED remains<br>
listening for new connections.<br>
<br>
What do you think?<br>_______________________________________________<br>
KDEConnect mailing list<br>
<a href="mailto:KDEConnect@kde.org">KDEConnect@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kdeconnect" target="_blank">https://mail.kde.org/mailman/listinfo/kdeconnect</a><br>
<br></blockquote></div>