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
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.