james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Cheng <jmch...@alum.mit.edu>
Subject Re: stream-based MIME parser
Date Mon, 12 Apr 2004 21:24:10 GMT

>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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message