On 10/30/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > On 10/29/07, Zsombor <[EMAIL PROTECTED]> wrote: > > <snip> > > > It would be good, if we can start to collect the requirements for the > > backend API, with the various protocols, which James currently supports, > or > > in the future supports. > > +1 > > <snip> > > care to start a page on the wiki (http://wiki.apache.org/james/) with > the content?
Yes, i've added here: http://wiki.apache.org/james/BackendMailboxAPI > > +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. > 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 :-) <snip> > > +1 > > the mime4j pull parser comsumes less memory, is usually more > performant (but could be much quicker) and is usually more accurate. > since it's our source, we can fix bugs and optimise performance. > > - robert > Great ! BR, Zsombor
