On 7/11/07, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
