(readded frameworks, the topic ping-pongs) 2012/9/18 Aaron J. Seigo <ase...@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. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel