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.



Makes sense. So that basically means, you're not dealing with a "modifiable" stream, so much as dealing with a "copying" callback handler. That's good, as it makes it easy for us to ensure that the common read-only case doesn't pay the performance/resource penalty that the read-and-copy case will necessarily require.

I guess the challenge would be redesigning the callback API to incorporate the output streams in a natural way.

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.


That being the case, would it be worth writing a standalone header-manipulation module? I was under the impression that JavaMail's fragile-ness in dealing with malformed headers was a big problem, at least as much of a problem as the resource consumption issue. It'd be relatively easy to write a module that loads the headers into memory, manipulates them, emits them, and then copies over the original body verbatim. Or would the lack of generality (i.e. not being able to modify the body) be too high a price to pay?

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.



The easy/natural way to allow for this today would be to wrap InputStream around the buffers (inside the parser's constructor, if you prefer)... any problems with that?

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to