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? Thanks for the help, Paulo F. > > BR, > Zsombor > > > ps. however I hope that you can contribute to the IMAP module, anyway :) > > > 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] > > > > > > > > >
