Notifications-future, a recap

[Dario Freddi]

(readded frameworks, the topic ping-pongs)

2012/9/18 Aaron J. Seigo <aseigo at kde.org>:
> On Monday, September 17, 2012 20:40:33 Dario Freddi wrote:
>> it's pretty much on the board :) just that 90% of this will happen in
>> the background (server), whereas handlers will just take care of
>> showing a model and a set of events. The aim is to make the client API
>> as simple as possible and have a fatter server.
>
> is the goal of getting rid of the notifications server as discussed at the
> Frameworks meetings in Randa off the table then?

Personally, I don't care about who is gonna be the "server" - and this
is also why I started the discussion. The ideas are:

1. A separate daemon, close to what we have now
2. An existing component behaving as a server.

Consider that when I am talking about a server it actually means "a
component implementing a DBus interface". I admit that my POV has
changed after 1 year and a lot of research, since I strongly believe
the client/visualization and server/dispatcher must be de-paired,
otherwise we wouldn't be able to make applications act as handlers.
But at the end of the day, we just need something implementing a DBus
interface. So I don't know - I kind of like the idea of having a
separate component, but even if it was a NotificationServer::init()
inside plasma-* it would still be more than enough.