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. 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. opinions? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
