Noel J. Bergman wrote:
note that mime4j only provides read-only capabilities at this time.
mime4j doesn't directly support creating or modifying messages.
This is something that could be worked on, though. :-)
Absolutely. :)
On the other hand, emitting RFC822/MIME messages seems like a much
easier problem than parsing them. The hard part IMO is coming up with
an API to let you work naturally with messages in a read/write fashion
while remaining performant and memory-efficient.
When do you expect to get mime4j loaded into source control so that we can
start looking at these areas, as well as just using it within JAMES?
It's up now:
https://svn.apache.org/repos/asf/james/mime4j/trunk/
Sorry, and thanks for the gentle prod.
To use mime4j in streaming mode, write an implementation of the
ContentHandler interface (or subclass SimpleContentHandler, which
automates header parsing and content-transfer decoding), then new up a
MimeStreamParser and call setContentHandler(ContentHandler) on it, and
finally call mimeStreamParser.parse(InputStream).
To use mime4j's DOM-like mode, you just use new Message(InputStream) to
create a message, then call methods on it. I can't be more specific
about the methods it offers, as I haven't used it much--this is Niklas'
area of expertise.
I'm currently working on getting the latter mode to work without using
temp files, when possible. The header parser is also missing the
ability to parse trace (i.e. return-path, received) and message-id
fields. Other than that, mime4j is ready to use (and in fact has been
in use in at least two production apps for several months). So far it
has proven completely robust for everyone who has tried it AFAIK.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
