On Jan 4, 2008 3:53 PM, Paulo Sergio <[EMAIL PROTECTED]> wrote: > Hi Robert, > i'm finally back to this issue :) > > On Dec 19, 2007 10:44 PM, Robert Burrell Donkin < > > [EMAIL PROTECTED]> wrote: > > > On Dec 19, 2007 4:05 PM, Paulo Sergio <[EMAIL PROTECTED]> wrote: > > > Hi all! > > > As some of you know i'm trying to implement IMAP IDLE. while doing it , > > i > > > need some way to notify the session of changes in the mailbox. > > > At the moment i have a service running on james startup, and receiving > > the > > > notifications, these notifications are received using jgroups. To achive > > > this i created a new service that starts at the initialization phase > > along > > > with IMAP server and remote management service, i know that Imap extends > > > from abstractjamesservice, instead my service (the notifications > > receiver ) > > > extends from AbstractLogEnabled and implements Serviceable, > > Configurable, > > > Disposable, Initializable, ObjectFactory, NotificationProvider. > > > NotificationProvider is an interface that means that this server can > > notify > > > for changes, and that it contains a list of listeners. > > > > sounds good so far > > > > > So after this "brief" description here goes the question: how can i > > register > > > Imapserver (or imapsession) as a listener for this service? > > > the idea is that when Imapserver (or imapsession) is notified it writes > > a > > > message to the client indicating the changes (folowing IDLE spec) > > > > this isn't the only way but i'd approach this by creating an adapter > > service that depends on both your new service and the imap service. > > upon initialisation, it registers itself as a listener. when an event > > is received it performs the appropriate call on the imap service. > > > > yes , this was my idea, but i seem to be missing some obvious thing... > please correct me if i'm wrong: > > - The services are all initialized at the same time, before starting to > accept connection from clients.
yes, that's the way avalon does stuff > - A client should only be on the "notifiable" list after it sends "IDLE", > otherwise it doesn't need to receive notifications > - The clients should be registered as listeners right after moving to IDLE > STATE . there are different approaches this but that way seems reasonable > The problem is : > - The List of listeners must be accessible from the service that is > receiving notifications > - The object that contains the list of listeners must be accessible from the > IdleProcessor that's one way to do it > from James architecture seems complicated to share this object... JAMES is based on IoC and messaging so communication through a shared object is less natural than a messaging based solutions (for example, delievering an event to all sessions. IDLE sessions would act upon this message whereas others could ignore it.) > Should it be part of the session object? > Should the session objecte be the one implementing the notifiable interface? > (it should be a component that has the ability to write responses to the > client) IMHO the best answer to this depends on the handling of the client protocol side. how do you intend to implement the IDLE command? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
