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 Sun, 28 Oct 2001 14:28:40 GMT

> That had occured to me. However, in that situation,
> that you have Mailets and Gemlets, you have to make
> sure that you are very disciplined to put all your
> code into the Gemlets, to make sure it is possibly
> reusable by future Gemlets. In that scenario every
> single mailet consists of one line of code:
>    Gemlet.execute("foobar");
> In that case you can just write one Mailet that
> handles every possible case with some config
> option telling it which Gemlet to call. And then
> Mailets become irrelevant.

Actually not irrelevant because you are still using a mailet, albeit only one.

The same argument can be leveled at many other technologies, in this context notably servelets,
it is theoretically possible to write a single sevelet which can process any expected request,
or to bypass servelets altogether and write a bespoke application which processes http requests.
The issue then becomes at what point the cut off between productivity and features drives
you down the route of creating individual servelets/mailets for every task, then your servelets/mailets
can become very simple too, drawing on generic classes which perform specific functions and
are highly re-usable, and not constrained to work within the context of a specific servelet/mailet

The added value is in allowing easy layering of the technologies so you rapidly arrive at
the specific functionality required, yet built from robust, tested and widely used components,
not your own ducttape, paper and string. You can then concentrate your teams expensive resources
on producing the application specific elements, not re-inventing the wheel.

In your scenario there is still a role for matchers, they will filter irrelevant requests
from your mailet/gem gateway and allow configuration settings alone (not hard code) to determine
what requests are passed to which, if any, gemlet.

IMHO, d.

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

View raw message