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]
