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 Wed, 11 Jul 2007 22:03:34 GMT
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.

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.

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

> so, i'd like to propose that JAMES looks for an alternative to
> MIMEMessage for server side work
> 
> requirements:
> 1. fully interface based API (not a subclassing framework)

+1 (even if subclassing has its advantages I also prefer the advantages
of interface based frameworks).

> 2. equal billing for nio and stream io

+1

> 3. first class support for raw access to bytes, second class for
> chars. third class support for object representations (if at all)

Right, we probably don't need object representations.

> 4. lightweight

no comment.

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

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

> 8. support for meta-data

can you elaborate?

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

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

> opinions?
> 
> have i missed anything?
> 
> - robert

I think all of this belongs to the mime4j project.
Do you plan to start working on something from mime4j code?

Stefano


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