Hi,
Please read to the end before you reply, it may be dull but I believe it's
important..
> Ah! You mean that <processor> creates an instance of class
LinearProcessor,
> which currently is hardcoded to launch the Mailet container. We can add
> flexiblity, making it possible to launch other containers, such as one
for
> Sieve, by specifying the container class, as in:
While I agree with the idea that we could, and should, permit other types
of processor my understaning was that a processor would always be a mailet
containing processor.
That a processor was a component which managed the workflow of mailets, not
performed the processing itself, linear processor might be complimented by
a putative conditional processor which interprets Mail attributes and
applies conditional routing, implementation language is immaterial, it is
the workflow routing that is the role of the processor.
That a Mailet was the atomic unit of processing and that any escape from
the Mailet API into any other system used to process the messages should be
done using a Mailet as a gateway.
I'm not adversely disposed to relaxing this but I'd like to know why we'd
choose a processor over a mailet for the role.
Some of my own thoughts on the subject are braindumped below..
A mailet and a processor have very similar interfaces, and in fact there is
no technical reason why they should't be the same, or share inheritance so
that they could be polymorphic wrt the two roles.
>From that respect we obviously consider in pratice if not explicitly by
design that Processor fulfills the role of a workflow controller, and a
mailet as the unit of work.
In any high level processing directive schema there is often the need to
compensate for a lack of procedural control by escaping to the underlying
programming language, escaping from a declarative to a procedural language
is very common and well understood.
If we consider that the mailet configuration is a declarative language for
defining workflow in the domain of email processing Noels proposal is
supporting the use of escapes into sieve and other scripting languages.
Now you could say that the mailet config is in fact nothing but a series of
escapes, every piece of decisionmaking and processing is implemented by an
escape to Java.
However the Mailet API formalises the escape in such a way as to allow
aggregation and composition to be used by the declarative configuration
syntax in a powerful flexible and portable manner, providing encapsulation
of processing behaviour and consequently reuse by non-experts.
I believe that this design principle, while not expressed, is one of the
strengths of James and the Mailet API.
If we are going to extend the idea to allow scapes to other languages, such
as sieve, I think this should be done according to the same pattern.
Lets consider a sieve processor..
1/ it MUST (IMO) be a workflow controller for units of processing.
2/ we should not lightly consider the addition of a new type of processing
component.
3/ sieve processing should be by a mailet which provides the sieve
environment.
Now, having writtent that I have realised ("at long last danny" you may
say!) that "Matchers" fulfill the role of decision making not for the
mailet, but as part of the workflow and therfore they should be considered
more as an attribute of the "Processor" than of the Mailet.
So what? Well.. perhaps we should be implementing a sieve (or whatever)
processor which can contain regular mailets, but instead of regular
matchers it would expect matcher definitions to be of Sieve code not
refrences to Java classes.
In which case we need to consider carefully the proposed changes to mailet
config, I would like to see matcher declarations be nestable, and contain
mailet declarations (rather than v.v) in order to better model this, and I
believe that we do need to model it as it does seem to be the assumption
upon which we've based a lot of our work.
I also believe (as Noel reminded us, thx Noel ;) that we shouldn't require
an admin to have any great XML skill, so _relying_ on namespaces is out
IMO.
An example of how I see this fitting together as a config is appended:
Thanks for reading this far!
d.
<?xml version="1.0" encoding="UTF-8"?>
<spoolmanager>
<processor name="root" class="LinearProcessor">
<matcher class="ALL">
<mailet class="ToProcessor">
<parameters>
<parameter name="processor">spamFilter</parameter>
</parameters>
</mailet>
</matcher>
<matcher class="HasHeader">
<parameters>
<parameter name="condition">JamesSpamFlag</parameter>
</parameters>
<matcher class="HeaderIs">
<parameters>
<parameter name="condition">JamesSpamFlag=TRUE</parameter>
</parameters>
<mailet class="ToProcessor">
<parameters>
<parameter name="processor">spam</parameter>
</parameters>
</mailet>
</matcher>
</matcher>
</processor>
<processor name="spamFilter" class="SieveProcessor">
<matcher class="Sieve">
<parameters>
<parameter name="code">{{in line Sieve code to match whitelists}}
</parameter>
</parameters>
<matcher class="Blacklists">
<parameters>
<parameter name="list-location">URI</parameter>
</parameters>
<mailet class="AddHeader">
<parameters>
<parameter name="header">JamesSpamFlag: TRUE</parameter>
</parameters>
</mailet>
</matcher>
<matcher class="SieveBlockPatterns">
<parameters>
<parameter name="import-code">{{URI of seive code to match
rejections}}</parameter>
</parameters>
<mailet class="AddHeader">
<parameters>
<parameter name="header">JamesSpamFlag: TRUE</parameter>
</parameters>
</mailet>
</matcher>
</matcher>
</processor>
<processor name="spam">
<matcher class="ALL">
<mailet class="NULL"/>
</matcher>
</processor>
</spoolmanager>
***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only.
If you are not the intended recipient (or responsible for delivery of the message to
the intended recipient) please notify us immediately on 0141 306 2050 and delete the
message from your computer. You may not copy or forward it or use or disclose its
contents to any other person. As Internet communications are capable of data
corruption Student Loans Company Limited does not accept any responsibility for
changes made to this message after it was sent. For this reason it may be
inappropriate to rely on advice or opinions contained in an e-mail without obtaining
written confirmation of it. Neither Student Loans Company Limited or the sender
accepts any liability or responsibility for viruses as it is your responsibility to
scan attachments (if any). Opinions and views expressed in this e-mail are those of
the sender and may not reflect the opinions and views of The Student Loans Company
Limited.
This footnote also confirms that this email message has been swept for the presence of
computer viruses.
**************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
