KDE-Connect and KDED

[Albert Vaca]

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.

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.

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.
On Mar 5, 2014 5:49 PM, "Àlex Fiestas" <afiestas at kde.org> wrote:

> On Tuesday 04 March 2014 13:02:57 Yuri Samoilenko wrote:
> > I think kdeconnect must operate like any linux/UNIX service(/etc/init.d/*
> > as example). Exception is in that /etc/init.d/* is system services,
> > required root access to manage them, but kdeconnect is user service. The
> > option that users can do is:
> > 1. start/stop service
> > 2. autostart service when login
> I don't see why anybody would care on restarting/starting/stopping kde-
> connect.
> It is something build in into your KDE session, if you don't want it just
> kill
> it, no?
> We should use almost no cpu/ram when idle anyway.
>
> > I look on KDED as on simple service manager with user interface fits
> > options above. Starting-on-deman is unnecessary(for kdeconnect) facility.
> >
> > >> Also, kdeconnect should be smart enough to kill itself if there is
> >
> > nothing to
> > Hmm, no. kdeconnect daemon must running all the time to plug current
> > device(desktop too) into kdeconnect-network. For example I need to share
> > info not only with my phone(with android) but with my notebook(with
> > kubuntu+kdeconnect aboard). So daemons must be running on desktop and
> > notebook all the time.
> >
> >
> > Sorry for possible misunderstanding of you mail.
> KDED modules are thought so we can put there logic that will be IDLE most
> of
> the times but we still need to have it running all the time. Thing for
> example
> of receiving files via Bluetooth, we need to be listening for "incoming
> files"
> all the time but we do not really need a new process just to do that.
>
> Translated to how we could use it on kde-connect, it would be perfect for
> the
> use case of "We need to listen for new devices all the time". So KDED
> would:
> -Emit broadcast messages
> -Listen for broadcast messages
>
> The moment somebody wants to actually talk with us, we fire up kde-connect
> and
> let it do the heavy lifting work.
>
> When no clients are connected, then kde-connect dies, and KDED remains
> listening for new connections.
>
> What do you think?
> _______________________________________________
> KDEConnect mailing list
> KDEConnect at kde.org
> https://mail.kde.org/mailman/listinfo/kdeconnect
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20140305/1ce8ad50/attachment.html>