Hi all, 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) Cheers, Paulo F. On 11/4/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > On Nov 3, 2007 4:44 PM, Zsombor <[EMAIL PROTECTED]> wrote: > > On 11/2/07, Robert Burrell Donkin < [EMAIL PROTECTED]> > wrote: > > > > > > On Nov 2, 2007 12:54 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > > > > Robert Burrell Donkin ha scritto: > > > > > the problem is that session is used in two different senses: > database > > > > > session and a session of a (session-oriented) protocol > > > > > > > > > > if you're using a transactional datastore then yes, you'll need a > > > > > datastore session to execute transactions but there is no > necessity > > > > > for this to equal the MailboxAPI session > > > > > > > > Maybe there are *3* different sessions: the protocol session (for > POP3, > > > > IMAP, SMTP), the mailboxapi session, the datastore session. > > > > Or you are saying that the MailboxAPI session will be the same as > (or 1 > > > > to 1 to) the protocols session? > > > > > > it's not clearly defined how the MailboxAPI session relates to the > > > protocol and database sessions > > > > > > i've done a class diagram for the interfaces in MailboxAPI see > > > http://wiki.apache.org/james/BackendMailboxAPI > > > > > > IMO this is excessively complex > > > > > > Yes, I feel the same pain :) And you skipped the drawing of lots of > wrapper > > classes :) > > IMHO the diagram was complex enough with just the interfaces :-) > > IMHO it would be simpler to factor the function in the wrappers into > POJOs and use delegation > > i also left out the complex series of factory classes above > MailboxManager. IMHO these would benefit from simplification. > > > in particular: > > > > > > * what is the difference between the various Mailbox interfaces and > > > the various MailboxSession interfaces? > > > * why are so many interfaces necessary? > > > > > > - robert > > > > > > > > I understand the reasoning behind the multiple interfaces - it tries to > > group various separate feature which the IMAP frontend needs from the > > backend (SearchableMailbox,FlaggedMailbox, etc) It is, i think a good > thing, > > i call this type of thing 'facets'. i like facets but IMHO it's more > usually to use facets to enable downcasting to discover whether a > particular implementation supports that particular group of functions. > > however, the current API is inconsistent: it has monsters such as > GeneralMailboxSession. IMHO it would be easier to comprehend the API > if either the facets were eliminated or consistently extended. > > ATM the API has half-a-dozen ways of getting an interface for a > mailbox scattered over several different interfaces. IMHO it's more > natural if the facets are retained to have a single, canonical way of > getting a basic mailbox which can then be downcast to a facet. > > > the problem lies in the mixing the Mailbox and the MailboxSession and > the > > wrapping of the objects. > > +1 > > plus the multiple factory classes > > > I'm not sure how to simplify the code, but I think, > > if i were the original author I would done in the following way: > > The backend constitutes the following class/interfaces : > > - MailboxName - it groups namespace,username,folder name > > +1 > > > - MailboxListener - similar to the current MailboxListener interface > > IMHO it would be more flexible to unify the calls by using an event > > > - Mailbox - with add/remove/expunge/search/flag functionality (probably > with > > some IMAP specific methods for getting unseen/recent count), The object > > should be stateless. For every MailboxName, it should be one Mailbox > object > > in the VM. > > +1 > > > - MailboxManager - the entry point for the backend, with the following > > methods: > > Mailbox getMailbox(MailboxName); > > void registerListener(MailboxName, MailboxListener) > > void unregisterListener(MailboxName, MailboxListener) > > i've been thinking about this and now wonder whether registration per > mailbox is worthwhile. if the listener used events then the > MailboxName could be obtained from a property. the listener could then > ignore any events not of interest. > > stefano hopes to support transactions and that implies some concept of > a session to tie operations together > > one of the current problems with IMAP is that the event feeding best > when external events can be distinguished from events generated from > operations performed by the current session so some concept of session > sounds like it's required. if the event exposed the session which > performed the operation then the listener would be free to ignore any > generated by it's session. > > > The IMAP module should contain the MSN number, UID mappings, and the > other > > 'mailbox session' related codes, but probably names as > Imap(Client)Session, > > which is a MailboxListener also to get notification from other clients, > and > > from itself. So the implementation of the IDLE command would be easier. > It > > just set the 'session' object to 'forwardEveryMailboxChangeToClient' > mode, > > until it receives the 'DONE' command. And in that mode, every > > MailboxListener method call results in an apropriate IDLE response line. > > > > What do you think? > > sounds good :-) > > any other opinions? > > - robert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
