Re: Introductions ... re noel

[Alan Williamson <al...@blog-city.com>]

> I agree with the latter, but the former is addressed by the aforementioned
> in-protocol handlers.  Perhaps you're just behind the times with JAMES.

I respectfully disagree Noel.

I don't wish to talk about JAMES.  Not because I don't value it as a 
project but because IMHO it has no purpose on a discussion list about 
the Mailet API.

We no more want to talk about Tomcat or JBoss when it comes to 
discussing the Servlet API.   JAMES is merely *one* container 
implementation of the Mailet API - we now have an alternative 
implementation in MailCatcher.

JAMES is probably suffering from being only the rooster in the farm; but 
that is something we would like to address and offer people a choice 
when it comes to Mailet containers.

If one wants to use the Servlet API again as an example, i see JAMES as 
the full blown "J2EE" reference implementation, where as the Mailet 
stuff, is like the Servlet Containers (ServletExec, Tomcat etc).

So the question boils down to this; does one want to see the Mailet API 
grow as a separate project, or is this really a JAMES discussion?

Re: Introductions ... re noel

[Stefano Bagnara <ap...@bago.org>]

Alan Williamson wrote:
>> I agree with the latter, but the former is addressed by the 
>> aforementioned
>> in-protocol handlers.  Perhaps you're just behind the times with JAMES.
> 
> I respectfully disagree Noel.
> 
> I don't wish to talk about JAMES.  Not because I don't value it as a 
> project but because IMHO it has no purpose on a discussion list about 
> the Mailet API.

I partially agree with this statement: I don't want us to make the big 
mistake to discuss an abstract api without concrete goals.

I think future "implementors" of the API are the one that should 
influence the API itself, and that we all (implementors) should work on 
something concrete and only after having tested it as working in a real 
environment try to standardize the API.

We should start creating a list of limitations of the current APIs and a 
list of things we believe should be feasible from a Mailet API user (the 
developer) perspective.

Once (if) we'll have agreed what features we want to support and what 
features we want to keep out from the apis we can discuss the best api 
to provide the required extensibility.

> We no more want to talk about Tomcat or JBoss when it comes to 
> discussing the Servlet API.   JAMES is merely *one* container 
> implementation of the Mailet API - we now have an alternative 
> implementation in MailCatcher.
> 
> JAMES is probably suffering from being only the rooster in the farm; but 
> that is something we would like to address and offer people a choice 
> when it comes to Mailet containers.
> 
> If one wants to use the Servlet API again as an example, i see JAMES as 
> the full blown "J2EE" reference implementation, where as the Mailet 
> stuff, is like the Servlet Containers (ServletExec, Tomcat etc).
> 
> So the question boils down to this; does one want to see the Mailet API 
> grow as a separate project, or is this really a JAMES discussion?

I think we should grow it as a separate project, but I think we should 
keep discussing about how currently James Server and MailCacher (and any 
other implementation around) is trying to solve commons problem with the 
current mailet apis or without them.

To understand better each other we should probably study each other 
products. I already download mailcatcher.zip  ...

Stefano

RE: Introductions ... re noel

["Noel J. Bergman" <no...@devtech.com>]

> 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