Alan Williamson wrote:
>> Danny Angus wrote:
>> Alan Williamson wrote:
>>> I am a little confused as to why Danny/Noel believe it isn't part of the
>>> Mailet API? What is the remit of the Mailet API? What is its purpose
>>> in life if not a hook for developers to process mails?
>> Yeah, but the API doesn't assume that the system doing the processing
>> is also implementing any of the mail protocols. It could be that the
>> mail is all sitting in an archive and needs to be mined for some
>> reason.
> Gotcha, that makes sense from that aspect.
>> Therefore protocol related API's are out of scope, but that doesn't
>> make it a bad idea.
> I guess this is always the balance, purist vs. reality. In reality the
> majority of mailets are probably being called upon the SMTP trigger,
> therefore it makes sense to involve that protocols behaviour in the API.
The Mailet API is driving mailets in a container that receives messages.
Usually those arrive in some sort of spool. The spool could be distributed,
and processed on systems that don't have anything to do with SMTP (or other
protocol) transports.
Look at it this way: the Mailet API has about as much in common with the
in-protocol handler API as a Message-Driven Bean has in common with the ORB.
They have totally different semantics, event structures, transport and
transaction issues, etc. This is why I object to conflating the two areas.
> you could make a strong argument, that the Matcher classes are
> invoked at the wrong part of the chain. Maybe they should be
> invoked as and when the email address is available, and not
> when the whole body has arrived.
Well, that is because you're conflating two different issues: Matchers,
which deal with selecting messags in a message pipeline, and in-protocol
handlers that act on events as they happen during protocol transfer.
Where we will have far more agreement, and where we are refactoring JAMES
code today, is that there are commonalities and places where you want to
factor out underlying behavior that can be shared by in-protocol handlers
and matcher/mailet code. So SpamAssassin can be invoked by an in-protocol
handler (more and more mail *filtering* code is done in the handlers), or it
could be invoked in the message pipeline.
As I said, more and more we're moving to handle filtering in the protocol
handlers, and have just "application" type code in the pipeline, e.g.,
mailing list managers, delivery support, etc.
--- Noel
