> 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 challenge would be redesigning the callback API to
> incorporate the output streams in a natural way.
I figured that we'd construct the handler with the object it can use to emit
data. That keeps it out of the package, and leaves it as an implementation
aspect of the handler.
> would it be worth writing a standalone header-manipulation module?
Isn't it just a subclass of "emitter" handler, which is only interested in
effecting a change to the stream's headers, and then streams the remainder?
> I was under the impression that JavaMail's fragile-ness in dealing
> with malformed headers was a big problem
That is a separate issue. It would be good to have a complementary package
that understands header formats. I imagine a callback class for important
headers, where the presence of an particular header would result in an event
for that header type, and we'd have support for parsing and presenting the
content of the header to the event handler.
> > 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?
Ignore my earlier comment. :-)
I wrote a long reply explaining issues with push and pull model programming.
In so doing, I went through some usage scenarios. What I realized is that
even when we have NIO support for James, it would not be necessary, or even
beneficial, to convert this package to use push model I/O. The SMTP handler
isn't permitted to abort a DATA command, so since we need to wait for it to
finish before we can reply, so we might as well do just that. Plus, the
SMTP ACL processor would not benefit. So as much as I like push model, this
is one of those cases where we're fine just as we are.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
