> does one want to see the Mailet API grow as a separate project,
> or is this really a JAMES discussion?
That still isn't the point. The point is that you are conflating two
separate and not really related issues: the Mailet API, which deals with
selecting and processing messages; and a protocol handler API for dealing
with in-protocol events. I am happy to discuss either or both, but not to
conflate the two. Again, as I said in my initial reply:
we have pluggable in-protocol handlers that are connected to such
events. I do not know that anyone wants to standardize on our in-protocol
plug-in architecture, which we're still evolving, but that seems separate
from Mailets.
The "fast-fail" (the original name for it, but "in-protocol handler" is
better since failure is just one application of it) API is separate from
matchers and mailets.
I also don't agree with your thought that:
> i agree with Noel that it shouldn't be part of the actual class:
> org.apache.mailet.Mailet
> But it should be another interface, that sits within the
> [org.apache.mailet] package.
I don't see it as being part of the Mailet package, but that's a
nomenclature issue. If there is interest in standardizing on that API, too,
that's still a fine idea.
--- Noel
