james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Let's Create An Alternative To MIMEMessage
Date Thu, 12 Jul 2007 20:20:19 GMT
robert burrell donkin ha scritto:
>> > 6. first class support for bytebuffer storage
>> > 7. support for IMAP requirements such as line and byte counts for parts
>> charser/encoding conversions would be needed for ESMTP/8BITMIME support.
> 8BITMIME is an IMAP extension
> from an nio perspective, both charset and encoding would be issues
> best left to the application. of course this then raises the
> performance issue of executing the same decoding multiple times.

I don't think that multiple conversions is a big deal. Btw we can do
some optimization by always keep the last conversion and change only if
strictly necessary.
E.g: if we receive 8bitmime mail and we have to deliver via 8bitmime
server then we can avoid conversion. If we receive 7bitmime mail we can
avoid conversions at all.

> not sure i have an easy answer for this
>> > 8. support for meta-data
>> can you elaborate?
> for example, JAMES attributes and javamail flags

Why does this need to be implemented IN the MimeMessage handling
structure? is this something that the MIME specification take into
consideration? Can't we keep the Envelope/MimeMessage paradigm and place
meta data in the envelopes ?
This is not to say I'm against metadata, just to better understand the
motivation behind the requirement.

>> > 9. support for outputting components of the message
>> So, what do you keep in memory? the mime structure? And if possible
>> pointers to streams for every parts (possibly shared) so that you can
>> lazy parse them when you try to output them using a different encoding?
> when using a bytebuffer, everything is already in memory so this is
> easy. doesn't sound very easy for streaming solutions though.

How do we deal with 1GB mime messages?

>> > 10. decoupled from javamail
>> +1 Maybe the resulting framework could be used to create an alternative
>> backend for javamail for legacy applications, but this is too far in the
>> future.
> just at the thinking stage ATM
>> I think all of this belongs to the mime4j project.
>> Do you plan to start working on something from mime4j code?
> not sure
> it sounds like there may well be issues in creating a general solution
> suitable for both streaming and bytebuffer backends. it may be that
> they are just too different.
> i'll probably protocol a clean API with an nio-centric MIME parser for
> IMAP. if something DOM-like would be a useful complement to the
> streaming SAX and (hopefully) pull parsers in Mime4J then we can tidy
> it up and discuss the optimum general solution later.


> i would like to expose more options for alternative parsers (as well
> as MIMEMessage) through the mailbox interface but i'll start another
> thread for that.
> - robert

Thank you,

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message