Noel J. Bergman wrote:
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.
I think that we have misunderstanding due to what handlerapi is in james
server and the concept of handling the data as soon as possible in a
stream based protocol.
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.
Currently Matchers can do almost everything a Mailet can do: they can
change the mail. Mailet also can do almost everything.
Imho we should put more constraint on Matchers: imho it would be better
to use them as message selectors and they should not be able to change
the message, but we already use some of them to add attributes and
similar things.
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.
Exactly, it would be good if we can find interfaces to access the
"underlying behaviours" so to make that common part, usable by both the
protocol handlers or by the "current" Mailets a common standard.
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
I agree, and that's why we should try to "evolve" the current API to be
more friendly with the new scenario where we need to have answers to our
processing early.
Myabe we can do this adding new unrelated apis, but maybe many things
can be done by improving the current interfaces.
Stefano
