RFC: Decouple the daemon from other parts of KDEconnect?

[Andy Holmes]

The protocol itself is pretty simple, and most of the code either
depends on Qt or KDE Libraries. Doing it this way actually makes a lot
of sense, since implementations should use native libraries
(TLS/Sockets, JSON, notifications) to integrate into their
environment.

I think a better idea would be an effort to document the base protocol
and plugins to make it easier for developers to write implementations.
There is some documentation of the protocol and plugins in the source,
but a larger document might open things up more.

On Mon, Jan 15, 2018 at 4:41 PM, Aleix Pol <aleixpol at kde.org> wrote:
> On Mon, Jan 15, 2018 at 7:45 PM, Mayeul Cantan <mayeul.cantan at gmail.com> wrote:
>> 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
>
> Hi,
> I'm sorry but I don't see how splitting will make it better.
> Otherwise, development will be harder.
>
> Maybe you can look into this issue from a packaging side?
>
> Aleix