On Nov 7, 2007 10:14 AM, Paulo Sergio <[EMAIL PROTECTED]> wrote: > Hi Gzombor, > > On Nov 5, 2007 5:31 PM, Zsombor <[EMAIL PROTECTED]> wrote: > > > On 11/5/07, Paulo Sergio <[EMAIL PROTECTED]> wrote: > > > > > > 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? > > > > > > With shared mailboxes and the NOTIFY extension the user can receive > > notifications about new mails. I don't know what do you want from external > > services, and how it is related to the IMAP protocol. Probably you can > > hijack this infrastructure, to add some custom IMAP command and response, > > but in that case, you have to write a specific client too, but I think > > it's > > simpler to write your own protocol, and own little server application. > > > > well, my architecture will have three main components: james server(acting > as the server that the clients will connect to), a web- service(witch will > act as James backend, containing all the mails and folders and validating > the user/password) and a third component that is a notification server > (witch will send a notification). > the notification will be sent to james server.. although this server will > only notify the server, and u would need it no totify the user session.. is > this possible? could you tell me where do i find info about shared mailboxes > and the notify extension?
this is awaiting implementation ;-) volunteers? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
