[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: Notifications-future, a recap
From:       Dario Freddi <drf54321 () gmail ! com>
Date:       2012-09-18 9:31:35
Message-ID: CAFFVnfM8Z0Okc8-+QYHStoqUKcYGC33CN1yysfXgLjTOV8V_Ww () mail ! gmail ! com
[Download RAW message or body]

(readded frameworks, the topic ping-pongs)

2012/9/18 Aaron J. Seigo <aseigo@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
[prev in list] [next in list] [prev in thread] [next in thread]