[sip-comm-dev] New notification service


#1

Hi,

As discussed offline with Yana and Emil, we'd like to implement a notification service to allow any bundles to call when needed a method that would display some on-screen information to the users. The implementation of this service would be OS-dependant (eg: using Growl on MacOSX, or the systray on Linux and windows).

I enclosed a draft definition of the service. It's actually quite similar to the service defined for the systray. Several questions I'd like to ask to Yana & Emil:

- I'd like to put the service in service/notification unless you'd have a better name for the service

- The NotificationService would define several type of messages (by a mean of a static field, eg INCOMING_MESSAGE_TYPE, etc.): for example, one for the audio calls, one for the Instant Message, etc. This means that the service may be extended each time a bundle would need to define a new class of message. Is this acceptable? I think this would be useful, so the implementation of the service could allow the user to select which type of messages it would like to display or not.

- The NotificationEvent would have the coordinated where the user clicked. Is it necessary to have other things? (eg: the message that was displayed, or its type?).

- For the implementation, I'd put the sources in
impl/notification/growl/
impl/notification/systray/
...

- All the current code that takes care of displaying on-screen messages (ie the listener code currently located in the growlnotification and the systray plugins) would need to be moved to a new bundle common to all OS, and that would listen to any kind of events (MessageListener, etc.) and call the notification function from the notification service. Any idea for the name and location of such bundle?

WDYT?

Cheers,

notification.zip (4.84 KB)

···

--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team


#2

Hi Romain,

Romain KUNTZ wrote:

Hi,

As discussed offline with Yana and Emil, we'd like to implement a notification service to allow any bundles to call when needed a method that would display some on-screen information to the users. The implementation of this service would be OS-dependant (eg: using Growl on MacOSX, or the systray on Linux and windows).

I enclosed a draft definition of the service. It's actually quite similar to the service defined for the systray. Several questions I'd like to ask to Yana & Emil:

- I'd like to put the service in service/notification unless you'd have a better name for the service

I agree with the name.

- The NotificationService would define several type of messages (by a mean of a static field, eg INCOMING_MESSAGE_TYPE, etc.): for example, one for the audio calls, one for the Instant Message, etc. This means that the service may be extended each time a bundle would need to define a new class of message. Is this acceptable? I think this would be useful, so the implementation of the service could allow the user to select which type of messages it would like to display or not.

Also agree.

- The NotificationEvent would have the coordinated where the user clicked. Is it necessary to have other things? (eg: the message that was displayed, or its type?).

I think that we could add the message, the type and also the timestamp,
when the event has occurred.

- For the implementation, I'd put the sources in
impl/notification/growl/
impl/notification/systray/
...

Ok for the first one, but the second could be called jdic, because we'll have another implementation with java 6.

- All the current code that takes care of displaying on-screen messages (ie the listener code currently located in the growlnotification and the systray plugins) would need to be moved to a new bundle common to all OS, and that would listen to any kind of events (MessageListener, etc.) and call the notification function from the notification service. Any idea for the name and location of such bundle?

I think that we could simply keep the systray, of course except the part that manages notifications, and it will be the bundle that will listen for new messages, calls, etc. and would call the NotificationService in order to show a message.

Another thins is that if we have the Notification service then we don't need anymore the Systray service, so we could remove it.

yana

···

Cheers,

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Yana,

- I'd like to put the service in service/notification unless you'd have a better name for the service

I agree with the name.

Great :slight_smile:

- The NotificationService would define several type of messages (by a mean of a static field, eg INCOMING_MESSAGE_TYPE, etc.): for example, one for the audio calls, one for the Instant Message, etc. This means that the service may be extended each time a bundle would need to define a new class of message. Is this acceptable? I think this would be useful, so the implementation of the service could allow the user to select which type of messages it would like to display or not.

Also agree.

Ok.

- The NotificationEvent would have the coordinated where the user clicked. Is it necessary to have other things? (eg: the message that was displayed, or its type?).

I think that we could add the message, the type and also the timestamp,
when the event has occurred.

Ok I'll add them to the definition of the service.

- For the implementation, I'd put the sources in
impl/notification/growl/
impl/notification/systray/
...

Ok for the first one, but the second could be called jdic, because we'll have another implementation with java 6.

Ok.

- All the current code that takes care of displaying on-screen messages (ie the listener code currently located in the growlnotification and the systray plugins) would need to be moved to a new bundle common to all OS, and that would listen to any kind of events (MessageListener, etc.) and call the notification function from the notification service. Any idea for the name and location of such bundle?

I think that we could simply keep the systray, of course except the part that manages notifications, and it will be the bundle that will listen for new messages, calls, etc. and would call the NotificationService in order to show a message.

Ok I agree. Keeping the systray to listen for the events and moving the service implementation in "jdic" for the notification via the systray is a good idea. My proposition did not allow to have both the systray and other notification service implementation (eg: growl) running at the same time, while your solution allows that.

Another thins is that if we have the Notification service then we don't need anymore the Systray service, so we could remove it.

Ok, I'll take care of that once the notification service and implementations have been completed.

···

On 2007/06/27, at 13:28, Yana Stamcheva wrote:

--
Romain KUNTZ
kuntz@lsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net