> So that basically means, you're not dealing with a "modifiable"
> stream, so much as dealing with a "copying" callback handler.
Right. I see two broad classes of handlers: sinks and emitters. Sinks just
eat the stream, whereas emitters output a possibly modified stream.
> I guess the challeng
> I haven't looked at the org.xbill.DNS.Address but it
> sounds like a good solution.
Agreed. I'll look at making that change.
> I have put it on my todo-list to go through the code and
> weed-out InetAddress, just haven't gotten around to it yet.
I just did:
$ grep --recursive "InetAddress\
noel2004/04/12 18:39:44
Modified:src/java/org/apache/james/dnsserver Tag: branch_2_1_fcs
DNSServer.java
src/java/org/apache/james/fetchmail Tag: branch_2_1_fcs
MessageProcessor.java
src/java/org/apache/jame
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
> 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
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.
In other words, even if you've parsed through the body once and have
somehow recorded th
Noel J. Bergman wrote:
Finding extra help is always nice, but I worry about
expanding our scope early on by including many projects'
objectives.
No interest in expanding scope. I don't see that the scope has changed
since we started talking about it last year, and I don't believe that it
would hav
> I would prefer to develop it here since we have a very tangible problem
> to solve.
We're in agreement on both the approach and the reasons.
> it might be worth looking at Alex's streaming codec, and
> adopting is a common interface for moving the data into
> the package.
> Finding extra help
