Looks like we are going to disagree on this issue Noel
Noel J. Bergman wrote:
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.
The message pipeline as you call it, in this instance is SMTP. The
pipeline *is* by definition a transfer; moving data from one place to
another. Doesn't really matter HOW that happens, thats protocol
specific. By your own logic, the fast-fail operations belong in the
Mailet API.
But lets wind back here, because I think you're being maybe a little too
pragmatic here.
"The Mailet API is an API designed to facilitate the development
and deployment of a configurable email processing applications"
That is lifted straight from the Mailet WIKI.
There is nothing in that statement that suggests putting in the
hooks/interfaces I have suggested would violate that statement; infact,
one argues it strengthens it.
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.
But that is JAMES specific. I am not interested in JAMES. If JAMES is
the only container implementing the Mailet API then this whole
discussion is somewhat moot and academic. How you guys handle it
doesn't really matter, since no one else but JAMES is using it.
If however, the group is keen for the Mailet API to grow beyond JAMES
then one has to look at where the vast majority of Mailet development is
going to be done by Java developers; listening to emails coming in from
SMTP. Can we at least agree on that? Everything else, JAMES will
probably do for them anyway.
This sort of dogma bogged down the early days of the Servlet API; many
argued that servlets were far more than HTTP. They were right; however
99.999999% of all servlets are attached to the HTTP protocol. Therefore
it quickly made sense to push HTTP functionality into the specification.
all fun fun on the frontline of API design!
:)
