[jitsi-dev] NotificationManager in NotificationService


#1

Hey

What was the reason to concentrate the registrations of notifications in the central class NotificationManager?

From my understanding, the NotificationService is a service (haha) to be consumed and depending on as few other other services (configuration, resources, util) as possible. Now with the dependency on UI, neomedia, the protocols, it is kind of a plugin that listens to events and no longer offering a service.

The reason I stumble upon this now is: I want to fire notifications from the DNSSEC resolver very early (during the startup of Jitsi). This became impossible since c9110 because e.g. neomedia is not yet loaded. (Granted, I shuffled around in the startlevels).

Regards,
Ingo


#2

Hi,

well the idea is to remove the notification triggering as they were
scattered all over the gui, and get them out of there so they can be
reused on places where the current ui is replaced by another
implementation (like on android for example).
Yes this can be added as a separate plugin, without much refactoring
as it don't depends on anything of the NotificationService
implementation.
Anybody else? Should we add new plugin for NotificationManager?
There is actually and a plugin for configuring notifications, or we
can combine them in one new plugin?

Regards
damencho

···

On Tue, Nov 29, 2011 at 6:54 PM, Bauersachs Ingo <ingo.bauersachs@fhnw.ch> wrote:

Hey

What was the reason to concentrate the registrations of notifications in the central class NotificationManager?

From my understanding, the NotificationService is a service (haha) to be consumed and depending on as few other other services (configuration, resources, util) as possible. Now with the dependency on UI, neomedia, the protocols, it is kind of a plugin that listens to events and no longer offering a service.

The reason I stumble upon this now is: I want to fire notifications from the DNSSEC resolver very early (during the startup of Jitsi). This became impossible since c9110 because e.g. neomedia is not yet loaded. (Granted, I shuffled around in the startlevels).

Regards,
Ingo


#3

Hey

well the idea is to remove the notification triggering as they were
scattered all over the gui, and get them out of there so they can be
reused on places where the current ui is replaced by another
implementation (like on android for example).

Okay, I get the idea.

Yes this can be added as a
separate plugin, without much refactoring as it don't depends on
anything of the NotificationService implementation. Anybody else? Should
we add new plugin for NotificationManager? There is actually and a
plugin for configuring notifications, or we can combine them in one new
plugin?

IMO, new, separate plugin. If the NotificationManager ends up in the configuration plugin, it is again inside a Swing UI dependent package.

This kind of ends in a general design decision - which bundle depends on which others? E.g.
NotificationConfig -> Notification -> Neomedia and UI
                                  >--> Config, Resources
NotificationConfig, Neomedia, UI, protocols -> Notification -> Config, Resources
NotificationConfig, NotificationBinder -> Notification -> Config, Resources
                                      >--> Neomedia, UI

The first example is a self-contained plugin, it listens on events from other services once it is loaded. If an event from a service is fired before the plugin is loaded, it is lost. Additionally, services that need to be loaded at stage before the plugin, cannot use the notifications.

In the second example, the notification service is a core component, the major services depend on it.

The third example separates everything. The notification service can be loaded early on, and the binder can connect each service once they are all loaded. Events fired before the binder is loaded are lost.

Regards,
Ingo


#4

Just had an offlist discussion with Ingo:

The simplest approach here would be to make sure that the Notification
Service Impl (NSI) starts earlier than all the other bundles that might
be using it.

This might imply however that the NSI may need to start before some of
its dependencies, like the GUI for example.

In order to have this settled we'll split the notification service into
a couple of bundles and take out the part that wires Jitsi events to
notifications.

Cheers,
Emil

···

On 30.11.11 11:32, Bauersachs Ingo wrote:

Hey

well the idea is to remove the notification triggering as they
were scattered all over the gui, and get them out of there so they
can be reused on places where the current ui is replaced by
another implementation (like on android for example).

Okay, I get the idea.

Yes this can be added as a separate plugin, without much
refactoring as it don't depends on anything of the
NotificationService implementation. Anybody else? Should we add new
plugin for NotificationManager? There is actually and a plugin for
configuring notifications, or we can combine them in one new
plugin?

IMO, new, separate plugin. If the NotificationManager ends up in the
configuration plugin, it is again inside a Swing UI dependent
package.

This kind of ends in a general design decision - which bundle depends
on which others? E.g. NotificationConfig -> Notification -> Neomedia
and UI |--> Config, Resources NotificationConfig, Neomedia, UI,
protocols -> Notification -> Config, Resources NotificationConfig,
NotificationBinder -> Notification -> Config, Resources |-->
Neomedia, UI

The first example is a self-contained plugin, it listens on events
from other services once it is loaded. If an event from a service is
fired before the plugin is loaded, it is lost. Additionally, services
that need to be loaded at stage before the plugin, cannot use the
notifications.

In the second example, the notification service is a core component,
the major services depend on it.

The third example separates everything. The notification service can
be loaded early on, and the binder can connect each service once they
are all loaded. Events fired before the binder is loaded are lost.

Regards, Ingo

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31