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 Mon, 29 Oct 2001 00:59:24 GMT
 >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.

This is not a hard-code versus config file argument. I've got nothing 
against a config file being one possible
option for setting up which messages go where.

Let's take another example. Let's say you've got this whiz-bang virus 
attachment filter. It does
everything under the sun to do with blocking emails you don't want. So 
you want *every* mail
to pass through it. But some people's emails, you want to block all 
.exe, without any question.
Some you want to block .exe viruses, some also want to block Word macro 
viruses. Some
you want to block zip that contain .exes, some you want to block .zips 
that contain
.doc or some with .zip containing .doc with suspected macro virus. Maybe 
some people
you want to block these things, except when they come from well-known 
email addresses
that you trust. And maybe some people are allowed an exception if the 
subject-line contains
a password.

Now you don't want to use the James Matcher system, because that would 
mean the
inefficiency, of  running the same virus checks multiple times, because 
there is a complex
set of rules and configuration for which options apply to each mail. You 
are however
keen to use a config file, because you don't want to hard-code it. So 
what you want
is for every mail to pass into this scanner code. The code analyses what 
it can find. It then
reads a config file to decide what to do about what it has discovered. Maybe
that config is very similar, maybe the same as what James has now. Maybe
it uses matchers very much like James to do that matching. But it won't 
be James,
and it can't be James because James won't give the Mailet that level of 
control.

But if the Mailet was given this little bit of extra control so that it 
can call other
mailets and matchers, and assuming James config file format is well 
designed for these
scenarios, you could have the same configuration infrastructure serving 
the cases
you have now, as well as these much more complex situations with a 
unified structure.

Sure, you could write this hypothetical virus blocker, with its own 
configuration
files, its own matching infrastructure, it's own plug-ins for custom 
handling. But why?
It's exactly the same problem set that James is already trying to solve, 
and to
re-invent it again doesn't make sense to me.

 >there is a compelling case for servelets to call one another, if you 
want to recurively generate and embed HTML snippets, however the way to 
deal with this is to extract the HTML >generation from the servelet and 
call that directly from the servelet, and from the recursed elements.

There is one difference with servlets. A generated fragment of html is 
not useful in itself. There is
no chance someone will write a servlet that produces only a html 
fragment and deploy that, because
html needs valid headers and footers.
This is a bit different to the mail situation, because here you may 
write a Mailet that does one
bit of processing and later wish to combine it with extra processing later.

 >The same argument can be leveled at many other technologies, in this 
context notably servelets,

Yes ok, but that's not exactly an argument. Just because technology X 
doesn't support Y doesn't mean
that Y is wrong or unwise.

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

You can have these generic classes, but your factoring and layering will 
tend to be constrained to be one level deep
because having written some Mailet that does X, using generic functions 
Y and Z, you won't be able to
build on that by writing Mailet W which is an extension of X. What 
you'll have to do is come back
later on and refactor it by putting logic X into it's own set of 
functions which Mailet W can call.

When you go down this route, all your generic functions, having fully 
factored all the logic out of the
Mailet, will all have pretty much the same interface - they will take a 
message as argument. At
that point, something like a Gemlet is born. Maybe someone else come 
along and writes a Gemlet
with a James-like XML format for dynamic configuration. And then the 
Mailet API would be dead.

Mainly because you don't want to support one feature - the ability of 
one Mailet to call another one.

Yes, maybe someday this will happen with servlets, I have no idea. Maybe 
in 5 years nobody writes
servlets as we know them because some smart cookie wrapped them with a 
nicer API.

 






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