Alan Williamson wrote:
Danny Angus wrote:
But to say it is outside of the current Mailet API, is wrong IMO. The
Mailet API is for the routing and handling of emails -- all we are
talking about is allowing the developer to make this decision much
faster/earlier.
Actually the mailet API implies a particular process which starts with
the full content of the message having already entered the system
okay i can buy that. As with the ServletAPI, i think we should consider
the possible of both. For example, the ServletAPI allows a developer to
process the incoming stream themselves if they want to kill the
connection at any point they can.
This is the very example I had in my mind :-)
BTW - I don't suggest for a minute we have a "getMailetInputStream()"
method, as that is way too ugly for even consideration! :)
I agree!
FastFail implies that an interest in the conversation carried out
during the protocol can result in decisions being taken *before* the
message has entered the system.
Well before the complete message has arrived. But surely we are already
protocol dependent. Think about it.
We have data that arrives on "MAIL FROM" and "RCPT TO" and that data is
presented in the Mailet API (aka the Matcher).
HOWEVER ... this information is not necessarily in the actual "DATA"
part. Therefore, if one was to dump the mail packet to the file system
(using whatever) then a lot of this data is lost already.
So to say the Mailet API has nothing to do with protocol is
contradicting the current API and specification. Is it not?
So my thought process is not to actually change anything, but to make
the Matcher stuff be called as soon as any email data arrives; not just
when they are all in.
You could create a partial Mail object as soon as the DATA command is
issued. This would give you everything but the body. If the
matcher/mailet try to read the body it will force to wait for the data
to be streamed, otherwise it could do its own matching/processing
anyway. The main problem is that we can't do this because until the data
is completed we don't know if that message is really arrived or not. We
can't start routing a message until we are not sure we "received" it
(until we received the CRLF.CRLF command and replied we accepted it).
What I think is that we should add the missing pieces to make this
"behaviour" effective and working.
Stefano
