Danny Angus wrote:
On 10/28/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
+1

I think (hope) we have subscribers in list that are not interested in
James but want to discuss and partecipate in votes about the mailet apis.

I'm not a big fan of mailet apis as a separate project from James, but
if we want to have a mailet api project that has its own workflow, and
maybe ever a separate team (maybe some other implementation author) imho
a specific mailing list must exists and a specific website would be even
help.

We either separate it from James server or we don't.

I totally agree.

I thought that you (James PMC) already decided that mailet-apis was a separate releasable artifact and had its own version. This is why I replied +1.

> I don't think we
should yet, because it isn't complete enough in itself to allow anyone
to really use Mailets in another context. Therfore I'm in favour of
leaving it for users, and working on server-dev@ until we have got the
API complete enough to move into its own sub-project.

d.

If the goal is a James Server api layer to the mailets then I think that we can also keep interfaces in the james.services package and we should simply concentrate on the removal of Avalon stuff (ServiceManager first of all).

In general I've not a strong opinion on the need of a "mailet-api product" but I simply like to have consistency: if it is a simple layer to write plugins to james (like the handlerapis) then we don't need to be so strict on different version numbers, the workflow is directly related to james-server releases and we don't need a specific list/website, otherwise it should be separated like any other james project we have (ala jspf) and we should keep the specific list and create a specific site.

Stefano

Reply via email to