james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@thought.co.uk>
Subject RE: James - GEM
Date Tue, 23 Oct 2001 21:03:43 GMT
I've been thinking more about this and I think that the issue is probably
centered around the idea behind processors.

Processors are dumb, linear, and in actual fact not really entities at all,
just a state of a message.

If processors were either
a) simple external scripts supporting conditional branching or
b) objects within which mailets could exist
(or both)
then in the first case you could set them up as text files, easily altered
and capable of being changed without stopping the server,
and in the second case they could act as a context for their mailets, and
would be potentially capable of managing the session information.

or not?

I do still think that James is primarily a mail/news server, and the mailet
API is there to be a bridge between mail/news protocols and applications.

Mailets can provide quite a lot of functionality, but there will always come
a cut off point, beyond which a complex application will be too constrained
by the architecture of the server to be able to run as a mailet. In this
case the mailet would be a gateway, forming a request based on a message,
passing the request to the application layer, recieveing the response, and
altering the message or creating new messages appropriately.

At this point an application which can integrate with James using the Mailet
API would be able to integrate with any server supporting the mailet API
(there are some about).
My point is that if you accept this scenario, that there is a limit to what
can be done with mailets, then isn't it better to keep the mailet system as
simple as possible, and encourage its use for simple mail oriented tasks and
as a gateway into more complex processing, than fall into the trap of
expecting too much from it?

Perhaps Chris ought to position GEM as a Mailet application server.

(just thinking aloud)


To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

View raw message