james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris <ch...@bitmead.com>
Subject RE: James - Gem
Date Wed, 24 Oct 2001 00:18:08 GMT

 >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.

I have a problem with this statement.Most Mailets implement the simple,
generalised, widely useful chunks of logic. Applications implement the
specific, complex, higher level logic. The trouble is that the high level
specific logic needs to call the generalised, widely used logic to get
the job done. The application specific logic needs to make use of
Mailets that send out mails, forward mails, and otherwise deal with
messages, and combine them and package them together for an end result.
What you need is a mechanism for creating primitive components
(you've got that) and a mechanism for packaging those primitive
components to make new components, (I think you're missing that).

 > 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.

In which case the application layer needs to be able to call on simple
generalised Mailets to get the job done. Building complex things
from glueing together simple things is what it's all 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?

How do you define "keeping it simple"? The core of Gem, excluding specific
Gemlets is about 1000 lines of code. That's simple by any standards. The 
gemlet
API is simpler than the Mailet API. Writing gemlets is simple. A Gemlet
that gets an email, splits off attachments, ftps them to a server in a 
directory
of today's date and then notifies a mailing list with a URL of the new file
takes about 40 lines of code. I could write a Gemlet that
could parse James mail files and execute Mailets, and it would have no
impact on the core of Gem. Or I could plug in an extension language like
Kawa scheme interpreter. You can't write a Mailet to do similar
because that Mailet wouldn't be able to execute the other Mailets.
Simple and powerful don't have to be an either/or decision.

Anyway, not wanting to start a flame war, only calling it like I see it.




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


Mime
View raw message