KDE-Connect and KDED

[Yuri Samoilenko]

Hello


> I don't see why anybody would care on restarting/starting/stopping kde-
> connect.
>

I talking about possibility to start/stop/autostart. How often do you use
system services in /etc/init.d/ ? I'am using it very rare(once per week),
but i CAN stop/restart ssh, samba, dedicated virtuaboxes, apache, ntp, bind
and so on.


> 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.
>

What do you talking about? kdeconnect daemon consumes just about 2.5 mb of
memory. All other memory(qt/kde libraries) already shared between desktop
environment. Listening on socket to wait for incoming data/connection is
not consuming CPU, so CPU usage for kdeconnect when idle is 0.0%.
ANY plasma/QML applet consumes CPU and memory _much_ more than simple
daemon that just listen port.

I'am agreed that KDED have little overhead to us, but there is no other
inretface in KDE environment to control daemons. There is no interface to
completly DISABLE something, or to temporary stop, except KDED.
KDE have a simple facility to autostart something
sytemsettings->administration->autostart but we can't disable or stop
runned process. Or start it without restarting whole KDE session.



> 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.
>


Actually kdeconnectd(but no kded module)  do this. KDED module(which
consumes just about 0 memory) just UI to start/stop daemon.  But your offer
additional layer which would start/stop processes and pass info(from
broadcast) to it. It is increase complexity and make "simple daemon" not so
simple as other UNIX daemons. The scheme you offer is used in apache, that
fork new process after establishing connection, but where apache and where
kdeconnect?
 If you want to save CPU or memory you should know that doing something
"just in code" is economical(and quick) than starting new process,
especially on Windows.

>> Albert: 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.

Any dbus service consumes more CPU and memory than simple kdeconnectd
daemon.

>> Albert: 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.

How you measured memory consumption related to kdeconnectd? I'am agree that
plasmoid can consume a lot of memory for QML engine, interpretter, GUI,
DBUS and other, But how can simple daemon can be fattest than any dbus
daemon or any other "frameworked" daemon?

To use ZERO memory user can completly disable kdeconnectd through KDED
module by just removing checkbox in systemsettings like many other KDE
services for example touchpad, remote control, nepomuk(!) and other.

Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20140306/d3596c82/attachment-0001.html>