KNotify-considerations for frameworks

[Aaron J. Seigo]

On Thursday, September 22, 2011 22:17:09 Sune Vuorela wrote:
> I'm considering doing some work on the knotify-stuff for the kde
> frameworks.

cool :)

> Currently, it is a quite complex framework that is hard to debug for the
> users of knotify (the application developers). It seems a bit
> overengineered, at least compared to how many of the features that is
> normally used.

i had to read your email a couple times to really grasp what you wanted to 
do.. maybe i still don't have it ;) but let's give it a try ...

first, a small correction:

> For Popup, which is the all-dominating case, it sends out a
> org.freedesktop.Notifications conformant message (galago spec)

that is only true if there is a galago daemon around. if there isn't, it shows 
a popup on its own. this guarantees that there is always a visual popup 
somewhere, regardless of what is happening elsewhere in the system.

now .. here's what i got from your email, please correct me if i'm wrong:

the big question is this: should we have a central daemon, or not? so probably 
a first question is: why do we currently have a daemon?

easy answer: it gives a central place for control and routing.

unfortunately, it also means a lot of dbus calls and a fair amount of 
complexity in the daemon itself. this means, in turn, high latency for events, 
more processes running (not great for start up costs and resource usage)

so is there a way to remove the downsides while keeping the upsides? the 
config dialog (which could use UI love, but that's a separate issue from the 
work on the technology behind the scenes) can be retained as long as the 
actions taken for events remain in config files. no daemon is needed for that 
at all. what would be needed is a way to tell applications that "notification 
settings have changed", and we have a way to do that already using 
KGlobalSettings. perhaps that could be extended to cover the notifications 
case.

centralized routing is probably of less value as long as it can all be 
controlled by configuration.

so .. the "how" to do this remains: what happens if the centralized daemon was 
removed? iirc from discussions at Platform 11, it could look something like 
this:

* the KNofication class handles the popup case directly: that's just either 
using KPassivePopup or dbus calls

* the rest of the options go into runtime plugins which are loaded by each app 
and run in-process for each additional kind of notification needed. so one for 
log file writing, another for sound, etc.

the downsides of this afaics:

* each app would need to load Yet Another Plugin on start up if they want to 
do anything beyond popups. (popus cold also be made into a plugin, but that 
seems a little bit like overkill?) this means a little more resource usage in 
each app and time to do the loading of the plugin. again, for the non-popup 
case (and sound is pretty common).

* code for plugins for, e.g., writing to log files might be a little more 
complex than they currently are since you can't just assume only one process 
is writing to that file. this is obviously a solved problem many years ago in 
the server world and not hard to do, but it could mean some small amount of 
added complexity for some plugins.

the above approach would mean:

* no loss of functionality (and easier to extend with plugins)
* lower notification latency
* 1 fewer process running to get a KDE app up on its feet
* the ability to easily strip out specific notification types from an 
installation
* the ability to keep compatibility with current code

how to improve the relationship between "what is in the config file" and "what 
the KNotification class lets you do" would be pretty easy to fix up in this 
scanario as well as it would all be in the same process (the class and the 
settings reading) and so harmonizing them becomes a lot easier.

did i understand your email correctly, and is the above a sensible re-
statement of your thinking?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110923/f023608f/attachment.sig>