Deploying UnifiedPush on Linux

I have previously written about how push notifications can be integrated on KDE Plasma Mobile and Desktop using the UnifiedPush standard. There are a few details still to work out though when looking at this from the wider Linux ecosystem perspective.

UnifiedPush on Linux

Applications on Linux interface with UnifiedPush via a relatively simple D-Bus interface. You can register and unregister for push notifications and get signaled the reception of such a message, that’s basically it.

There’s one detail in this though that is a bit surprising: There is no unique D-Bus service name for the push notification distributor, there’s merely a prefix defined. This implies that there can be multiple distributors co-existing and it is up to the applications to select which one to use.

And there’s another aspect not covered by UnifiedPush at all, namely how a push distributor is configured by the user and how the user is shown what is currently using push notifications and why. That’s left to the distributor implementation, which in a world with multiple distributors and multiple desktop/mobile shells/environments can get messy quickly.

Goals

To see why those are challenges for deploying UnifiedPush in a Linux environment, let’s look at what we actually want to achieve here:

1. Robust and reliable push notifications.
2. (Battery)-Efficient implementation.
3. Transparency and control for the user.

For (1) we would want to avoid applications having to deal with migrating/hopping between different distributors, as that would be rather error prone and brings in considerable complexity. For (2) we’d only want a single distributor having an active network connection, ideally even just a single distributor running. And for (3) we’d need a single place to see all active applications and configure push notifications.

Possible solutions

One possible change that comes to mind would be actually requiring a unique D-Bus service name for the UnifiedPush distributor. That however isn’t such an easy and comprehensive solution as it might initially look like. First of all there are reasons for the current approach, such as enabling applications that can implicitly act as a distributor (some chat clients on Android can do that for example). And secondly, only just because something is registered on D-Bus with the same name doesn’t mean it’s also the same thing. Distributors contain state which needs to be carefully managed (and cleaned up).

I suspect we’ll need a slightly more elaborate solution for coordinating multiple co-existing distributors. This could involve some mechanism to determine/negotiate the active one for example, between each other and applications wanting to use push notifications.

Another possibility could be a joined distributor implementation for Linux with an additional D-Bus interface for configuration and managing active applications. On top of that appropriate user interfaces for the respective shells could then be implemented.

And there are quite likely more options still.

Linux App Summit

Good thing we have just the right event coming up for discussing such topics, the Linux App Summit, next weekend in Brno, Czechia.

I’ll talk about this topic right after the opening keynote on Saturday, 11:20 in track 1, and I hope we can discuss how to solve the above mentioned issues. See you there!