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? > - custom properties for mail, the MIME structure is important, but some > useful imap extensions needs others, for example CONDSTORE/QRESYNC as I > remember needs a 'transaction number'. i think that being able to associate meta-data would be good > Other features, which we want to consider comes from the deployment > scenarios : > - db only backend > - db for the metadata, file system for the data, in maildir/mbox/custom > format > - db less backend, pure file system > - mixed backend (for example, the user mailbox are in a db, the shared, > read only mailboxes are on the disk. > - jcr backend > - james servers in front of the same backend (probably db-only, or jcr) +1 > Ok, am I missed something? front ends :-) BIO verses NIO; mina verses excalibor; concurrent command processing > 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) <snip> > i've been considering using Mime4J instead to allow generic > > information to be obtained about the structure. this requires (as > > jochen suggested) factoring out a suitable interface for the pull > > parser. i hope that this would be good enough to allow backend > > optimisation without coupling so strongly to IMAP. > > I cant understand, why Mime4J is better than javax.mail to collect > information about a mail message, and why it's better for the backend to use > that one, but honestly I'm not too familiar in either of them. In my > hibernate based backend, I was able to use MimeMessage, and worked fine. > If it's more performant - consumes less memory - than I'm with you, but I > think if we can cache the resulting information in the backend, that it > doesn't really matters :) +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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
