>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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
