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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
