KUnifiedPush in KDE Review

[Volker Krause]

On Mittwoch, 8. Februar 2023 13:11:52 CET Aleix Pol wrote:
> On Tue, Feb 7, 2023 at 6:36 PM Volker Krause <vkrause at kde.org> wrote:
> > Hello everyone,
> > 
> > I'd like to get KUnifiedPush
> > (https://invent.kde.org/libraries/kunifiedpush) through KDE Review.
> > 
> > KUnifiedPush contains the client-side building blocks we need for making
> > use of the UnifiedPush (https://unifiedpush.org/) push notification
> > standard.
> > 
> > In particular there are three parts:
> > - an application-side client library
> > - a client-side push notification daemon ("distributor")
> > - a KCM to configure the preferred push provider and to see registered
> > applications
> > 
> > We might want to split out the application-side part eventually, to not
> > mix
> > platform and framework parts, but that shouldn't affect the review.
> > 
> > Open issues:
> > - this is only working for the D-Bus part of the UnifiedPush spec, there
> > is a start of an Android implementation but that is still non-functional
> > if the app isn't running while the platform receives a push notification.
> > That needs some understanding of both the Qt <-> Android integration and
> > the Android mechanisms around broadcast receivers and the restrictions on
> > those, help very much welcome.
> > - while this is generally functional and usable, actual deployment is also
> > depending on having a default push provider (the server side part). There
> > have been a few discussions at FOSDEM on how to progress that.
> > 
> > For more background, there has been an Akademy talk on this, and there is
> > a
> > writeup of that here:
> > https://volkerkrause.eu/2022/11/12/kde-unifiedpush-push-notifications.htm
> > l.
> > 
> > Thanks!
> > Volker
> 
> Hi Volker,
> This sounds great, super encouraging to see progress on this front!
> 
> I was wondering, what's the reason to include this in libraries rather
> than frameworks directly? Is it because of the current state of KDE
> Frameworks transition? 

unclear policies regarding adding things to the frameworks group mainly, when 
I use frameworks directly I get told to use something else, when I use 
something else I get told to use frameworks :)

> I see that KUnifiedPush already sees itself as
> tier 1 (which is probably also something to address since it has a
> number of KF dependencies).

The application-side part is only depending on Qt::DBus so far, the extra KF 
dependencies are for the KCM. Splitting would fix that as well.

Following discussions with the UnifiedPush team about push message encryption 
OpenSSL might become an additional dependency. Technically message encryption 
is something to be solved on the application layer, UnifiedPush just passes on 
opaque messages and thus can't ensure encrypted content. But it's probably a 
good idea to have a recommended default implementation around (RFC 8188/HTTP 
ECE).

> Splitting it would make sense, but I understand this is something to
> happen at least with Plasma 6 as Plasma 5 is feature frozen.

Right. There's no time pressure as we need the server side sorted out as well 
anyway. The only reason this is still mainly 5-focused is that it started 
early last year already.

A split would look like this I guess:
frameworks/kunifiedpush - containing src/client, src/interfaces and src/shared, 
with the latter turned into public API.
plasma?/kunifiedpush-distributor - containing everything else, and a copy of 
src/interfaces, and depending on frameworks/kunifiedpush for what's now in src/
shared.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20230208/f1feb5c1/attachment.sig>