Hi Robert, On 11/5/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > On Nov 4, 2007 8:21 PM, Paulo Sergio <[EMAIL PROTECTED]> wrote: > > Hi all, > > hi paulo > > > i've been following the discussion and i would like to give my > opinion > > (although i'm not an expert). > > i think we are forgetting an important thing, we are designing an API > > thinking about the existent protocols, although i think we should think > also > > in what's next :) . > > > > In my case, i'm currently working in a web-service backend for james > using > > IMAP as a "front end protocol". Now i would like to start working in a > push > > mechanism, and i think about implementing IMAP Idle, i would have a > server > > sending the notification to james server, witch then would send the > > notification to the client. > > > > Well, this is one of the problems i think james has (correct me if i'm > > wrong), it lacks any type of push mechanism. > > In my case the server could send a session id to james, indicating what > > client should retrieve the new mails, the problem would be to get the > > session of the user that should be notified.. > > > > > > in my opinion i believe we should have some king of way of sending a > > notification/event to the mailbox or even better to any session, these > > would be send by an external server (my case) or by events sent by james > > server (ex: when a message is received, check if the user is connected > and > > if it is send a notification to the session) > > ATM the API allows mailbox listeners to be registered but the current > interfaces aren't great. a single method accepting an event is more > concise and extensible than including all calls in an interface. > > IDLE was touched upon earlier. Zsombor suggested that listeners would > registered at the mailboxmanager level. if the API were switched to > use events then every listener could receive events for every mailbox > and then ignore any that were of no interest. novel events could be > injected into the system by the backend implementation. listeners > would ignore any events they did not understand. > > would this mechanism be good enough?
i believe so, but you mean that each user connected would be able to register as a listener and then be notified when something happens? what about notifications from an external service ? how will these work? Thanks, paulo f another open question is whether an explicit API session would be a > useful to tie things together. something like a session would probably > be needed to reduce the number of factory method calls required to > obtain an API for a particular mailbox. > > - robert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
