New notification service

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,
-- 
Romain KUNTZ
kuntzlsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team






------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Hi Yana,


On 2007/06/27, at 13:28, Yana Stamcheva wrote:
>> - 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 

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

-- 
Romain KUNTZ
kuntzlsiit.u-strasbg.fr
Louis Pasteur University - Networks and Protocols Team


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net