Serge Knystautas wrote:
>
> Stefano Mazzocchi wrote:
> > Please, allow me to summarize the intents for everybody that is
> > involved:
>
> +1 (woohoo!)
>
> > 2) A "mail application" is created by mapping one or more mailets to one
> > or more entry points in the servering environment.
>
> Do we store these in a MAR file (like JAR and WAR file)? ;)
This is something we should aim to at the very end.
Just add something like
/MAIL-INF/mail.xml
in the zipped archive and JAMES will add this to its own configurations
on its own.
(Fede, consider this a future requirement: your markup syntax should be
clusterable to allow this easy drop-in)
> > So, the needs in the Mailet API can be outlined as:
> >
> > a) mailets should have commodity access to all information contained in
> > the SMTP send transaction.
> > b) mailets should _NOT_ require knowledge of the outter serving
> > environment in order to do their job. This means: a mailet should be
> > placed in all pipeline locations without requiring recompilation.
> > c) mailets design must be full programming-oriented, but should _not_
> > assume the knowledge of transport protocols.
> >
> > So far, so good.
>
> +1 on all (thanks for stepping back and restating what we have agreed
> and what we need to work out... makes all the views seem much closer to
> agreement)
I'm happy we reached this point :)
> > I would reshape it a little like this
> >
> > <application recipient="*@apache.org">
> >
> > <structure>
> > <match name="spam-matcher">
> > <mailet name="log-spam"/>
> > </match>
> > <match condition="* where (recipient is local)">
> > <mailet name="local-delivery"/>
> > </match>
> > <mailet name="remote-delivery"/>
> > </structure>
>
> I'm liking this a bit more, but what about...
>
> <structure>
> <match>
> <name>spam-matcher</name>
> <mailet>log-spam</mailet>
> </match>
> <match>
> <condition>* where (recipient is local)</condition>
> <mailet>local-delivery</mailet>
> </match>
> </structure>
>
> Yes, it's a bit more verbose, but storing the data as elements instead
> of attributes makes it easier to comment out and I think makes it a
> little more readable.
The element/attribute quest is the oldest one in the SGML world and many
experts believe this is a religion on its own. The pattern that is most
used (but still not bullet-proof) is:
"when you have something that belongs strictly to the element and can
only appear once, use an attribute, otherwise use an element."
So, not counting verbosity (which is of little concern)
<match name="spam-matcher" mailet="log-spam"/>
is better then
<match>
<name>smap-matcher</name>
<mailet>log-spam</mailet>
</match>
for a couple of reasons:
1) commenting out one of the "attributing" elements would break
functionality (what you want to comment out is the match)
2) if adding parameters as elements, you'd need to use the same nesting
level
<match>
<name>smap-matcher</name>
<mailet>log-spam</mailet>
<parameter>
<name>blah</name>
<value>blah</value>
</parameter>
<parameter>
<name>blah</name>
<value>blah</value>
</parameter>
</match>
which is not only more verbose, but rather uglier to XSLT-transform.
> You can still validate this with a DTD, and it
> doesn't suffer from the extensibility problem like mine did awfully.
> But wait... isn't that condition looking horribly unvalidateable? I'll
> assume this was just a quick example...
yes, I didn't touch the condition language on purpose.
> > <components>
> > <mailets>
> > <mailet name="log-spam" class="SpamLogger">
> > <parameter name="repository" value="my-spam-repository"/>
> > </mailet>
> > <mailet name="local-delivery" class="LocalDelivery"/>
> > <mailet name="remote-delivery" class="RemoteDelivery">
> > <parameter name="delayTime" value="21600000"/>
> > <parameter name="maxRetries" value="5"/>
> > </mailet>
> > </mailets>
> >
> > <matchers>
> > <matcher name="spam-matcher" class="SpamAnalyzer">
> > <parameter name="spam-repository" value="..."/>
> > </matcher>
> > </matchers>
> > </components>
>
> I suggest similar changes from attributes to elements for components and
> matchers. Again, it makes it much more verbose, but it's amazing how
> much more readable things become with all those quotation marks.
This is totally subjective. I find this syntax to be the most readable
and I generally disagree in using elements instead of attributes when
attributes make sense (reason why I hate the Servlet 2.2 DTDs)
> > I know Serge will have a negative feeling about that recipient matching
> > for applications, but I still consider the mail recipient to be the most
> > used case of reaction, since it's the most important identifier used for
> > email transactions, just like URI for HTTP and IP addresses for TCP/IP,
> > even if tons of others parameters are used during the protocol operation
> > and resource negotiation.
>
> Alright, I'll give a -0.2 on this, and easily outvoted. You've worn me
> down. :) You've got support for more powerful matching to still happen
> in the conf file, and without recompiling. Just be sure we can support
> recipient="james*@list.working-dogs.com" as most listservs are moving
> towards this concept, and it's just nice to have more flexible wildcard
> support.
Yep, don't worry.
> I've got several more emails to go through, but I'm generally happy with
> the direction. I think I'll draw up a servlet context and add it
> somewhere to CVS. I still argue that the mail servlet/mailet should
> return a boolean, but I'll have to show how easy it is to send a new
> email back into James using the servlet context, so I'll hold on that
> point for now.
>
> Also, are we moving back towards calling this a mailet instead of mail
> servlet? I really don't care... neither name wins awards in my mind,
> but then again, servlet was awkward to say at first.
I've been convinced that Mail Servlets is somewhat wrong, given the
actual working context of servlets. In a perfect world we would have
Servlets, then Weblets, then Mailets. Today "servlet := weblet", so
let's not make "servlet := weblet := mailet" and draw at least a
distinction.
+1 on Mailets from now on.
--
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]
