Robert Burrell Donkin ha scritto: > MimeMessages are expensive to create.
I see you wrote this twice in 2 messages: have you measured it? I never ran a real benchmark but I know MimeMessage sources and the way we subclassed/wrapped it and I don't see what is expensive there. I just want to go deeper in this because you used it as the "cause" for "action needed" in 2 recent proposals. While I agree that javamail is far from being a good server side api I don't think that MimeMessages are expensive: I can see problems in the way they expose their content, but not in their "cost" (either in term of memory or cpu). The main limitations in javamail are in the store/transport implementations: they are indeed client specific. Maybe it is strategic to not bind our API to javamail (I'm not sure, but this may have advantages, so why not) but indeed if we keep a similar/equal structure/naming for basic interfaces it would help both porting and learning. Why not to try to extract the Headers interface from the javamail InternetHeaders class? InternetHeaders already exposes this methods: public Enumeration getAllHeaders() public Enumeration getAllHeaderLines() public Enumeration getMatchingHeaders(String[] names) public Enumeration getMatchingHeaderLines(String[] names) public Enumeration getNonMatchingHeaders(String[] names) public Enumeration getNonMatchingHeaderLines(String[] names) I agree that List<String> is easier to use than Enumerations but I prefer to keep compatibility and similarity when the "pros" are not so big. JAMES Server's MailHeaders could then "extends InternetHeaders implements Headers". Stefano MessageResult > (http://svn.apache.org/repos/asf/james/server/trunk/core-library/src/main/java/org/apache/james/mailboxmanager/MessageResult.java) > was recently patched to allow headers to be returned without the > creation of a MimeMessage. the API introduced was: > > /** > * Gets headers for the message. > * @return <code>Headers</code>, > * or null if [EMAIL PROTECTED] #HEADERS} was not fetched > */ > Headers getHeaders(); > > /** > * Details of the mail headers for this result. > */ > public interface Headers { > /** > * Gets all header lines. > * @return <code>List</code> of <code>String</code> header lines, > * in their natural order > * @throws MessagingException > */ > List getAllLines() throws MessagingException; > > /** > * Gets header lines whose header names matches (ignoring case) > * any of those given. > * @param names header names to be matched, not null > * @return <code>List</code> of <code>String</code> header lines, > * in their natural order > * @throws MessagingException > */ > List getMatchingLines(String[] names) throws MessagingException; > > /** > * Gets header lines whose header name fails to match (ignoring case) > * all of the given names. > * @param names header names, not null > * @return <code>List</code> of <code>String</code> header lines, > * in their natural order > * @throws MessagingException > */ > List getOtherLines(String[] names) throws MessagingException; > } > > this is pretty much just pulling out the calls required. > > IMAP FETCH ENVELOPE returns parsed and processed header data. ATM this > uses MimeMessage and is therefore slow. > > perhaps it might be better to introduce a Header object and replace > Headers with a simple list (plus predicates to find the sublists). as > well as properties for the line, name and value, the header could also > expose simple parsing into address lists, dates and so on required by > ENVELOPE. it does mean more intermediary objects but would result in a > concise API. > > opinions? > > -robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
