Serge Knystautas wrote:
>
> Federico Barbieri wrote:
> > This looks to me like "flexibility syndrom"...
> > forcing only references instead of instances is a way to keep confs
> > ordered and avoid to have configs in two different palces which may mess
> > things up.
> >
> > What is the purpose of doing things in two ways is one is enought? Just
> > confusion.
>
> I have to agree with Federico on this one... -1 to offering two ways of
> configuring the mail servlets. A single section to initialize and map
> all servlets to simple names is IMO the best way to go.
But I do see the need for small configuration changes... for example:
<match id="checkHeader">
<parameter name="sender" value="[EMAIL PROTECTED]"/>
</match>
instead of
<match id="checkSenderIsStefano"/>
and later
<match id="checkSenderIsStefano" class="whatever.CheckHeader">
<parameter name="sender" value="[EMAIL PROTECTED]"/>
</match>
This could easily become a nightmare of "ids".
> On the subject of configuration, I think we're letting conf options get
> out of hand (myself included).
Hmmmm.. Federico is great at making things more abstract and complex to
complete visual symmetry :), but he's right when he wants to describe a
"complete" model.
Note, also, that it's algorithimcally certain to move from a nested tree
to a series of indipendent pipelines. It could be done directly with
XSLT.
> I really don't think we need nested
> functionality... I think servlets should handle determining whether it
> has handled the message delivery...
I totally agree and this is what I was trying to say with my proposal...
even if I agree with Federico that a flat tree is not much different
from a tree, complexity-wise.
Also I know (Federico and I already discussed a lot about this), a tree
can be changed in a series of indipendent but partially overlapping
pipelines. A tree is the less verbose representation but the most
difficult to visualize (IMO).
> I still don't think you should be
> able to return a different message and should add a feature to the Mail
> message to either 1) add methods to send a new message from the servlet,
> or 2) provide a method to grab the "servlet context" (the mail server)
> from which you could then send the message. I prefer the latter because
> a) it models the http servlet engine where you can have "application
> scope" variables, b) it seems untenable that servlets have to know the
> mail server's XML conf file format to get something like the
> postmaster's address, and c) adds some useability to the API that
> currently relies on a lot of static field names.
I agree.
> On routing for mail servlets, like I said I don't think we need nesting
> logic... I think we ought to explore how a MailDispatcher (like an http
> RequestDispatcher) could work...
-1
I'm currently fighting on the Servlet API list underlying all the
problems that RD have introduced, please let's not start here again :)
I believe (and I'm sure Federico is with me on this), that pipelines
should be fully componentizable without the need to rewrite code. Why?
Because, no matter how hard configuration is, programming is harder.
Component models allow, in theory, an application to be built just with
components and no other necessary logic, but only the wiring between
them. JavaStudio was a very interesting try on this direction, but it
failed because of the small granularity of its components (if/then was a
component!).
Now, in the MailServlet proposal what soon caught attention was the
pipeline architecture that allowed one to create a pipeline out of
already built components and create ad-hoc functionality, almost like
assembling lego bricks.
Each pipeline should be componentizable without the need to modify the
source code. Just like, in Avalon, you should be able to create a server
out of server components, even if you don't have their source code.
True, this requires that some of the programmability is moved into
configurations, which could generate problems later on when
administering. But I believe we should not worry about that at this
layer. (see below).
> and I think we should move closer to
> Stefano's hardcoded checks on message-servlet mapping. However, instead
> of only supporting only name="" (functions off of recipient), we should
> develop a set of standard message attributes you need to check (not
> want). I propose the following possible conf managed mapping checks:
> 1. recipient
> 2. recipient is local (the mail server will know whether the recipient
> falls within a domain that this server claims to handle, configured in
> one place)
> 3. sender
> 4. sender is local
> 5. ip address (of remote connection)
> 6. host name (of remote connection)
> 7. subject
> 8. message size
> 9. multipart
> 10. spam (more on this later)
> 11. all (send everything... save it for the last mapping)
to me, it is evident this is a dangerous path. why? because no matter
how hard we try, somebody will think in the future about something we
couldn't see today.
markup is _never_ written specifically for an application, or, if it
does, it's written when the scope of the application is limited and
doesn't change in time.
It's not the case around here.
> Then assuming elsewhere in the conf file we've specified instances of
> mail servlets and mapped them to simple names, the servlet mapping part
> would look something like:
>
> <servlet-mapping>
> <servlet-name>mylistserv</servletname>
> <recipient>james*@list.working-dogs.com</recipient>
> </servlet-mapping>
>
> <servlet-mapping>
> <servlet-name>StoreInMailbox</servlet-name>
> <recipientislocal />
> </servlet-mapping>
>
> <servlet-mapping>
> <servlet-name>RemoteDelivery</servlet-name>
> <all />
> </servlet-mapping>
>
> The DTD would define a servlet-mapping tag of having exactly 1
> (required) servlet-name tag, and exactly 1 (required) "condition" tag,
> which is one of <recipient>, <recipientislocal />, <sender>,
> <senderislocal />, <ipaddress>, <hostname>, <subject>, <size>,
> <multipart>, <spam />, and <all />.
strong -1
This is the least forward compatible way of dealing with components:
hardwire the components you have _today_ into a DTD.
What if I want
<multipartContainsXML/>
<machineLoadIsHigh/>
<lostGPSSignal/>
<comesFromSMSRelay/>
...
and so forth? How do you validate your configuration if every minor
release which adds a new matcher requires a change in the DTD?
> The more I thought about it, anything beyond very simple condition
> concepts is beyond the scope of administration and would more properly
> be put into the mail servlet itself.
I disagree. Component Oriented frameworks are in general easier to
maintain that Object Oriented programming languages. Why? exactly like
robotic lego is more RAD than handcrafting your robot in metal, and just
as effective.
> This combined with a
> MailDispatcher concept would give plenty of flexibility while keeping
> the admin simple and free of programming.
Ok, if I have to choose between programmatic configurations and internal
mail dispatching, I'd choose the first one. Why? Because I can easily
picture a visual tool to compose my pipelines like bricks, which I
cannot using Java code. Plus doesn't require compilation, it allows
automatic update of the components and all the usual benefits you gain
from componentized frameworks.
> Here's how I think the
> MailDispatcher would work (very primitive right now)...
>
> on MailServlet, you add....
>
> public MailDispatcher getDispatcher(String servletName);
>
> MailDispatcher would look something like...
> public interface MailDispatcher {
> public void forward(Mail mail);
> public boolean include(Mail mail);
> }
What you are proposing is a way to "hardwire" one servlet to another
one... what is the difference from creating a library of methods and use
them in your servlet?
> Ok, I haven't completely figured out why/how we would implement the
> differences between forward and include. I also don't know what exactly
> you'd pass to get a Dispatcher... is this the servlet's class name, is
> it the instance name set in the conf file?
I think you're using symmetry as a programming metodology and this is a
very dangerous path, like you told me before :)
> I guess a getServlet would
> work just as well, but at least according to the wisdom of the http
> servlet spec people (which I think is justified), they removed
> getServlet, because this gives direct access to other servlet
> instances. You should be able to interact with other servlets for the
> purpose of routing issues... not for the sake of passing other
> parameters or other things that getServlet allows.
I also fighting for having getServlet() back undeprecated and dealing
with security problems within the container security manager, like it
should be. There are cases (i.e. Cocoon) where it would be helpful to
have a servlet calling another one directly, being able to fake both
request and response for pre/post processing issues.
But this is another story.
> As for spamming, I think this is such an important issue, the mail
> server should bundle prebuilt spam detectors that get called before any
> servlet runs. This is probably an optional feature, but defaults to
> true. As more people submit spam detectors, we keep adding them and
> perhaps make the configuration the thoroughness to which it determines
> whether it's spam... simplest checks are just for known bad addresses
> and some simple ip address checking to prevent relaying. More thorough
> checking would go to MAPS or another 3rd party service that blacklists
> spammers, or perhaps doing other authentication against the to/from
> headers. Thoughts?
While I totally like your ideas about spam detection and such, I still
believe it is just another component.
What Federico is trying to do (wisely, IMO) is to create a complete
framework for componentizable mailet pipelines.
The only argument I had against it's proposal was the complexity of the
programmability that resulted, which is the same argument people are
using against marked-up languages like XSLT.
But either using trees or a bunch of partially overlapping pipelines,
I'm way in favor of adding programmability to configurations rather than
inducing changes in the components.
The point is to create a markup that is flexible enough for what we need
today and in the future without being utterly complex.
But we should also keep in mind that, being XML, many transformation
alternatives are already present, plus it's easy to create markup as
serialization of visual layouts.
Comments?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
