> Just want to make a note that my MIME parser currently presents you with
> streams that are non-seekable, non-markable, and non-writable. Not sure
> if anyone was expecting anything different, but there it is.
For matchers those should be fine. For mailets, we would want to be able to
process to a point, emit content for a new header or part, and then
continue. I am imagining it as:
MimeMessageSource -> MIME Parser -> Event Handler(s) -> MIME Stream
If we want Mail to be re-writeable, we'd probably implement it there. I'm
thinking something like:
new MimeParser(mail.getInputStream(),
new MyHandler(mail.getOutputStream()).parse();
That would not work today. Just mulling the idea.
> (I still don't have a great mental picture of how exactly the parser
> will fit into James, so I'm just going to throw some limitations out
> there and you guys can tell me if they matter.)
> Also, it seems like the codec guys consider emitting MIME to be just as
> important as parsing it... the stuff I've written will not help at all
> for that. And I've implemented the parser in terms of InputStreams,
> which the codec stuff consciously avoids.
Emitting MIME is more important for some mailets, and they could use
JavaMail to do it until we had a way of doing it with a streaming approach.
Most that want to change something just want to change headers, envelope or
attributes.
If the codec folks wanted to help with emitting MIME, that would be one
place for contribution.
As for InputStreams, that fits with all of the other James code today. I'd
like to see the code morph in the future so that buffers of data are pushed
into it, but that wouldn't stop me from starting to make use of it today.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
