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 Sun, 28 Oct 2001 10:18:51 GMT
> In this case it would be good to standardize the Action/Handler interfaces 
> and message interfaces but I think that is independ of Mailet API. In a way I 
> could see that Gemlets could sit ontop of a Mailet in much the same way as 
> Struts or Turbine sit on top of Servlet API.
> So I would say that Gemlets may provide a good framework/infrastructure to 
> build on top of something like the Mailet API.

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:

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.

Once that happens, Matchers fall victim to the same
fate. Partly for exactly the same reasons as
Mailets, and partly because once Gemlets take
control, (presumably because processing is
complicated), they want to do their own matching
on whatever complicated basis the app requires.
Since they can't call James' matchers, Gemlets
would have their own matching system.

You compare the situation to servlets. I think
servlets were originally designed to push out
html pages. Since joining two html pages
together doesn't result in a valid html page,
all you need is the choice to create html or
make a decision to forward to a different
servlet. These days JSPs are usually pushing
out the html, and servlets are gluing together
business logic and JSPs. Maybe if servlets
were thoughtfully redesigned today a case
could be made for calling one servlet from
another one.

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

View raw message