If I understood the proposal the input to the IOHandler are lines and I
can see performance issues for the DataIOHandler.
The rfc say that SMTP lines cannot be more than 998 bytes so we would
have to call DataIOHandler for each 0 to 998 bytes line to fill the
message stream.
I'm not sure this is good.
Otherwise maybe I didn't understand the proposal for the DataIoHandler.
Can you elaborate on this? I think that having a good solution to Data
is critical to decide wether this proposal is good or not for us. It
wouldn't be good to work the first 90% and discover later that the next
10% is not feasible or a bottleneck.
Btw if anyone is willing to do the 90% with this "open issue" the rest
of the proposal makes sense to me even if I don't have the time to
analyze the impact on the codebase.
Stefano
Noel J. Bergman wrote:
Norman came to me with some discussion about the work he is doing on the
fast-fail material, and I want to summarize the back-channel discussions.
The first topic that came up was how to have somewhat better control over
how the handler chain is executed. Norman had not seen the Servlet Filter
API, with its approach to chaining, so I introduced him to that API, and
with some input he is adapting those ideas to our code. His initial work
can be seen in today's commits.
Once you start down this road, you realize why the Servlet Filter API had to
deal with wrapped response objects, since you don't want downstream handlers
to have direct access to writing a response. Norman ran into a problem with
simply having handlers provide a response object, since a few handlers
introduce a separate issue: modality.
Currently, I/O comes into the SMTP server, which takes each line, assumes
that it is of the form:
<command> <arg-list>
and passes it along to be dispatched to the handler chain for that command.
The problem occurs when some command, e.g., AUTH or DATA, wants to perform
some I/O in a unique modality, such as the AUTH command providing its own
prompt and wanting to read the response.
My strawman is to replace the assumption with --- for lack of a better
term --- an I/O handler. The normal I/O handler is just the command
dispatcher. Each line as it comes in is handed off to the I/O handler (aka
command dispatcher) to process, and the response found in the session is
written back over the socket. But when we need to enter a nested state,
things change just slightly.
Let's use the AUTH command as an example. It currently does:
onCommand:
prompt user
read credential
process credential
return
Notice the problematic nested I/O modality. The new proposal would
eliminate this nested modality by breaking the operation up into two states
instead of one, and providing a new I/O handler:
onCommand:
push credential handler onto I/O stack
set SMTP response
return
Credential Handler:
pop I/O handler stack
process credential
set SMTP response
return
This concept may be easier to understand with some code, so I wrote a simple
and quite raw program to illustrate the ideas.
Please keep in mind that this is just a strawman and starting point. The
key idea is inverting the I/O modalities, breaking them up into managable
states maintained by a simple state machine with a stack to simplify state
transition. I have identified a few states: command, auth-credentials and
message, but I haven't really gone looking for others. Since all of the
states transition are nested, a stack-based FSM makes sense.
This code just points out a direction, and is compatible with supporting
both blocking and non-blocking I/O. It is not intended to show the details
that would be necessary, for example, to handle inserting the additional
data transformation code necessary for accumulating the message after the
DATA command registers a new I/O handler. Nor did I try to show buffering
interactions. But you will notice that there isn't any I/O anywhere except
for the test driver. If all of our protocol handlers and data transform
code were incorporated into this model, we'd be golden for java.nio.
My thought is that we travel down this road for all except for DATA as Phase
I, which gives us 90% of the support for a fraction of the effort, and then
having gotten more experience with our implementation, we move onto DATA as
Phase II.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
