On 10/26/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > from https://issues.apache.org/jira/browse/JAMES-808 > > > Currently the implementation of the FETCH command is not very efficient. > For example to > > retrieve one mail the following conversions will happens: > > 1, the backend creates a MimeMessage from a file/database blob/thin > air/etc > > 2, the frontend converts into a byte array, with correct CRLF line > endings. (I don't get, why it's > > needed, every incoming MimeMessage is already in this format, isn't it > ?) > > 3, the frontend appends it into a StringBuffer in the FetchCommand class > > 4, after some String manipulation it gets sent over an > InternetPrintWriter which checks also that > all line endings in correct style. > > this mess is the primary reason why the current implementation is > unreasonably slow. i've been running alternative code on my local fork > and the implementation is now quite enough to be usable. > > > I'm not sure that the whole thing is absolutly necessary. > > i'm sure that it is unnecessary > > IMHO the approach in JAMES-808 is the right one (adding more function > and options to > http://svn.apache.org/repos/asf/james/server/trunk/core-library/src/main/java/org/apache/james/mailboxmanager/MessageResult.java > ) > but there are a few broader design issues around MailboxManager that > i'd like to throw open for wider debate > > in terms of general API design, i tend to prefer to use subsidary > objects to tie together data. so (for example) i prefer a Headers > interfaces and a getHeaders method rather than adding three or four > header related methods into the general API. > > AIUI MailboxManager was intended to be a general API without coupling > to any particular protocol (please jump in if i have this wrong). if > this is still a useful design requirement then we need to do something > a little more sophisticated. > > in particular, the structure use cases are difficult. here, IMAP needs > to know about the outline structure of a message: if it's a mime and > if so, it's composition. JAMES-808 approaching this by returning > protocol specific values coupling the API to IMAP.
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. - POP3 needs - 'username+password' -> 'inbox' mapping, - listing of the content of inbox, with subject only (?) - getting the content of an email by it's id - deleting messages from the inbox - SMTP needs - 'email address' -> 'mailbox' mapping - putting an email into the mailbox - NNTP needs - ???? I don't know :) - Internal James API needs (spooling, fetchmail, etc): - handling various 'spool' 'mailbox'es, adding and removing items to them. - IMAP needs: - handle mail specific flags (Answered, Deleted, Draft, Flagged, Recent, Seen...) - ability to search by various header parameters (From, Subject...), flags - handle mailbox hierarchy per user (this would be nice for JSieve also, as I know) - shared/readonly mailboxes (this is optional) - 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'. 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) Ok, am I missed something? 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. 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. 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 :) BR, Zsombor
