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).
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) 2. equal billing for nio and stream io 3. first class support for raw access to bytes, second class for chars. third class support for object representations (if at all) 4. lightweight 5. easy partial and lazy parsing 6. first class support for bytebuffer storage 7. support for IMAP requirements such as line and byte counts for parts 8. support for meta-data 9. support for outputting components of the message 10. decoupled from javamail opinions? have i missed anything? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
