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)? ;)
> 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 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. 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...
> <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.
> 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.
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.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
