KService as a platform abstraction framework?

[Nicolas Fella]

On 03.07.21 10:25, Volker Krause wrote:
> Hi,
>
> while looking at implementing a pretty straightforward KApplicationTrader/
> KIO::ApplicationLauncherJob use ([1]) for Android, I found myself wondering
> whether we should have an Android backend for KService.
>
> KService conceptually matches android.content.pm.PackageManager/PackageInfo
> [2, 3], ie. the platform API to list installed applications and their
> respective features (essentially what's in the Android manifest XML files). In
> detail it however is full of .desktop file specifics, and leaks platform
> implementation details (e.g. KService inheriting from sycoca types).
>
> KIO::ApplicationLauncherJob is also something that makes sense conceptually on
> Android, implemented on top of Intents there.
>
> Has anyone thought about/looked into using KService as platform abstraction
> rather than as an functional/platform implementation framework already? I
> could imagine this to also be relevant on Windows.
>
> Is anyone aware of a current use on Android relying on the .desktop based
> implementation of KService? That might be theoretically possible, unlike for
> ApplicationLauncherJob.
>
> And while retrofitting platform abstraction support into KService wont be
> pretty, the alternative approaches (a new abstraction framework on top, or let
> applications deal with that with platform-specific code paths) aren't exactly
> convincing either.
>
> Thoughts?
>
> Thanks,
> Volker
>
> [1] https://invent.kde.org/plasma-mobile/qrca/-/merge_requests/35
> [2] https://developer.android.com/reference/android/content/pm/PackageManager
> [3] https://developer.android.com/reference/android/content/pm/PackageInfo

Hi,

I think overall it makes sense.

In our ongoing KF6 work we tend to move away from using KService for
non-application cases (plugins and kparts). Assuming we fully execute
that quite a bit of stuff then can be dropped from KService. That should
make it easier to adapt/make it less awkward to retrofit Android support
then. I think it's worth going over the KService class and investigate
how much of it will be relevant on a post-KF6 world.

Some XDG-isms are going to remain, but as long as it's just a bunch of
properties this should not be a big issue.

Cheers

Nico