RFC: Decouple the daemon from other parts of KDEconnect?

Mayeul Cantan mayeul.cantan at gmail.com
Mon Jan 15 18:45:55 UTC 2018


Hello there,

Yeah, I know, I haven't been active on KDEconnect lately, and my first
plugin project is still where I left it quite some time (almost a
year) ago.
Anyway, I was having a discussion on the #postmarketos about a way to
connect phones to the computer trough a USB cable, and it occurred to
me that KDEconnect was a pretty convenient solution, instead of
reinventing the whole sftp-over-network-over-usb thing (which works
with KDEconnect, if you have never tried, just put your phone in
tethering mode).

So, as I see it, kdeconnect is made of multiple parts: a daemon, a gui
and a cellphone client.
Currently, the daemon and the gui live in the same repository, and the
client is android-only.

I have seen some effort in the direction of allowing multiple daemons
to communicate with each other (to send files to other computers). But
I am not sure that it is capable of everything the client can do.

What I would like to see is the repository being split up, with the
daemon living in its own repository (maybe with a name such as
deviceConnect or something, to make it sound a bit less intimidating
to non-KDE members). It could be in turn ported to postmarketOS and
serve as a backend for cross-device communication.

In my understanding, the daemon could almost be capabilities-agnostic.
That is, just serve as an authentication and discovery mechanism
between devices (maybe even negotiate to drop TLS over USB?).
Consumers and Providers running on the device could then register some
capabilities with the daemon trough a d-bus interface. This way,
different devices and graphical interfaces could easily talk to each
other in their favorite language/protocol.
Actually, this might also start as a separate project and then serve
as a back-end to KDEconnect.

So, what do you think of this proposal? Any remarks or suggestions?

Please understand that I am in no way a major contributor to either
postmarketOS or KDEconnect (yet?). I am just connecting dots here. I
might also have (wrongly) assumed something about the architecture of
any component.

Best, and thank you for your hard work,

Mayeul


More information about the KDEConnect mailing list