james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "robert burrell donkin" <robertburrelldon...@gmail.com>
Subject Re: Let's Create An Alternative To MIMEMessage
Date Thu, 12 Jul 2007 19:46:58 GMT
On 7/11/07, Stefano Bagnara <apache@bago.org> wrote:
> robert burrell donkin ha scritto:
> > i've been thinking for a long while of using a replacement for
> > MIMEMessage as an intermediary representation in IMAP (and possibly
> > elsewhere in JAMES). i know that stefano advocates using a lazy
> > loading MimeMessage but i've taken a good look at this and IMHO this
> > is too much effort when it comes to IMAP: tuning a MimeMessage for
> > IMAP is too inefficient (fixing the buggy parsing would require
> > reparsing the message).
>
> To clarify my position: I hate javamail ;-). BUT I often complained some
> common javamail FUD because I had to learn javamail internal very well
> to have a somehow working MimeMessageWrapper/CoWProxy in JAMES Server.

yeh - nice work, that

> What I say is that often MimeMessage is extensible enough to apply
> optimizations and more, the problem is that no one did that and that
> doing this in javamail is much more difficult than creating from
> scratch. On the other side, if you create new interface you bind your
> code to yet another interface.

yes, it's a tough choice

it is extensible but it is a subclassing framework and this imposes
costs. it is read-write and input stream based whereas IMAP needs
something quick, read-only and nio-based

> That said, I think that Mime4J can be used and your mimemessage needs
> should be solved in mime4j and used by JAMES Server.

maybe so

> > so, i'd like to propose that JAMES looks for an alternative to
> > MIMEMessage for server side work

<snip>

> > 5. easy partial and lazy parsing
>
> A problem we may have is for shared streams accessed by multiple threads
> at the same time: javamail has the concept of SharedInputStream
> interface for this to be performant and avoid wasting resources.
> Do you plan to support something similar?

this is an example of complex that is unnecessary from the nio
perspective: the contents of a read only bytebuffer can easily be
share by as many threads as necessary.

i can see that this would be tricky when dealing with a stream.

> > 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.

not sure i have an easy answer for this

> > 8. support for meta-data
>
> can you elaborate?

for example, JAMES attributes and javamail flags

> > 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.

> > 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

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


Mime
View raw message