On Oct 30, 2007 10:50 AM, Zsombor <[EMAIL PROTECTED]> wrote: > On 10/30/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > > > On 10/29/07, Zsombor <[EMAIL PROTECTED]> wrote:
<snip> > > > > +1 > > > > > Ok, am I missed something? > > > > front ends :-) > > > > BIO verses NIO; mina verses excalibor; concurrent command processing > > You mean, we want a backend API with callbacks and j.u.c.Future-s ? It would > be enormous rewrite, or we need a compatibility layer over it. not right now ;-) one of the more subtle issues i discovered is that there's a tendency to focus on just on particular type of client for the API for example, in the current API to perform an operation, it's necessary to create a session. however, sessions are heavyweight: performing extensive pre-emptive caching. this is fine when dealing with heavyweight session oriented front ends but not so good for lightweight front ends. IMAP is session oriented but this design decision in the MailboxAPI results in poor performance for any calls that do not run against the selected session. then there's concurrency: how should the responsibility be split between the API implementations and the call? one requirement that is missing from the list and which is difficult ATM are events (i think that this is missing from the list). IMAP requires that the client is informed about changes that are made. so, the MailboxAPI some way to push events out. (this is currently not working very well and requires revision.) > > Some important, or nice to have feature, which we > > > want to support ? Any hidden protocol, which I've forgot ? Is there > > other > > > dreams about the future of James? :-) I know, from some of the features > > are > > > very far from the current codebase - for example the clustered james > > > deployment - others are simple matters of time, and interest - for > > example > > > the hierarchical db less backend. > > > Anyway, the main thing which I want to say, we should collect the > > features, > > > which we want to have, and mark the features which we dont think it's > > > important in the near, or far future. For example adding web-services to > > > James, or to become an email specific JCR server (I'm not sure it is > > > meaningful :) ), I think it's not so interesting/important, but probably > > > others thinks other way. > > > > the cool thing about open source is that you never know when someone's > > going to show up with an itch. if someone has the energy and skill to > > add web services then i say: great :-) > > > > but i agree that we're probably going to duplicate effort and make > > things harder if we don't organise some sort of reasonable list of > > features. we can then highlight any architectural dependencies. > > > > > My main preference is to have an easy deployable IMAP server, which > > stores > > > their data in a database, works over TLS or STARTTLS, and supports the > > > mobile friendly IMAP extensions. > > > > storing mail in a JCR is my itch but i need to sort out the MailboxAPI > > first > > > > (well, ok - actually replacing IMAP with a RESTful protocol is my long > > term aim) > > > Yes, that would be nice, but which email client will it support ? I don't > want to write one just for this :-) But definitely it would be nice,to have > one, with a nice web frontend :-) define the protocol and they will come ;-) but this is orthogonal - if the MailboxAPI is well design, this should not introduce any new functions. yes, it will be internally stateless but IMO the MailboxAPI should be able to cope with stateless protocols as well as stateful ones. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
