Fair enough. For what it's worth, +1 from my side. This is something
super necessary.

Let's decide where it ends up landing when it's a good moment to
decide. At the moment, considering Plasma 5 is frozen sine die, we
better keep it outside of it all. IMO.

Thanks!
Aleix

On Wed, Feb 8, 2023 at 6:15 PM Volker Krause <vkrause@kde.org> wrote:
>
> On Mittwoch, 8. Februar 2023 13:11:52 CET Aleix Pol wrote:
> > On Tue, Feb 7, 2023 at 6:36 PM Volker Krause <vkrause@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