Stefano Mazzocchi wrote:
>
> Serge Knystautas wrote:
> >
> > 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>
IMHO match should be simple enought to have just ONE "configuration"
parameter and that's why I've placed that parameter into the condition
line instead of having it separate:
It's just a matter of sintax but I prefere
<match id="checkHeader=sender:[EMAIL PROTECTED]"/>
I really think match do not need more complex configurations.
>
> 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".
>
Having the conf (or parameter) inside the condition line keep away the
need of ids. If match are simple enought you can use instances instead
of names and that makes thigs a bit simplier
> > 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).
Beeing the less verbose makes it earier to administer since it's not
redundant.
So if you want to change the behaviour of a big portion of your pipe you
just need to change a single point and not all linear pipes involved.
Not beeing reduntand means you avoid "cut-and-paste" which (I'm sure you
agree on that) is evil.
>
> > 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.
Agree. I've discussed this with Pier too and we arrive to a point. I'll
write about it later.
>
> > 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).
+1
> >
> > 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
>
-1 for me too.
That's exactly the reason for "pluggable" Match classes. A Match is
defined by a work interface but implement whatever logic the coder wish.
>
> 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.
Thaks for "wisely" :-)
>
> 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.
I just prefer complexity than verbosity. Anyway the tree IMHO is not
complex (hard to understand) since it's a very old programming pattern.
I know it's new for configuration but since the parallelism is evident I
really belive we should take all advantages of tree configurations.
>
> 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?
Ok. I know Stefano is going to flame me but that's my purpose... :-)
The processing pipe is nothing but a mailet. One mail cames aout of the
spool and is passed for processing to the pipe. Nothing goes out (exept
for errors).
So exactly as I've done as example for my tree processing pipe (which is
a Mailet) we can provide different processing pipes on administrator
choice.
I can provide a tree oriented or a linear or whatever we can think
about. My point is that the needs of a ISP are much different from what
a company mail-application designer needs and so on.
I'm not talking about bunch of different pipes... just two or three
different implementations.
So if I do not ave any local users I can just set as processing pipe
only the RemoteDelivery , if I have 10000 local users all with the same
configuration I can use linear pipe while if I have 20 users but each
deals with a mail application a tree conf may be needed (or vice versa).
So I was thinking 'bout writing something like
<processorLine>
<mailet class="ProcessingPipe">
<node type="match" condition="All">
<node type="match" condition="RecipientIsLocal">
<node type="mailet" name="LocalDelivery"/>
</node>
<node type="mailet" name="RemoteDelivery"/>
</node>
<mailets>
<mailet name="Null" class="Null">
</mailet>
<mailet name="LocalDelivery" class="LocalDelivery">
</mailet>
<mailet name="rootForward" class="Forward">
<forwardTo> scoobie@localhost </forwardTo>
</mailet>
<mailet name="RemoteDelivery" class="RemoteDelivery">
<delayTime>21600000</delayTime>
<maxRetries>5</maxRetries>
</mailet>
</mailets>
</mailet>
<errorMailet class="Null">
</errorMailet>
</processorLine>
... Or
<processorLine>
<mailet class=LinearProcessingPipe>
...
</mailet>
<errorMailet class="Null">
</errorMailet>
</processorLine>
etc.
You can take a look at the ProcessingPipe and Pipe mailet on the CVS.
opinions?
Fede
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
