> I think JAMES could really stand for branching logic, something like how the
> Sieve protocol works is nice. The best idea I've heard was to support
> nesting matchers and/or chain them. I'm not sure what you're suggesting as
> an alternate though.
Let me tell you some history of GEM. It is a total re-write of something
someone else wrote. In its previous incarnation, it was configured
with XML. Configs would look something like...
<process>
<split-attachments>
<mailet name=forward-to>
<parameter name=to>[EMAIL PROTECTED]</parameter>
</mailet>
<mailet name=ftp-to>
<parameter name=server>ftp.foo.com</parameter>
<mailet>
</split-attachments>
</process>
The above might split off attachments and forward them to someone
as well as ftp it to a particular machine. This paradigm solves
a slightly different area of problems than James XML idea. Still,
what it comes down to in the end is trying to make XML into a
programming language. James's XML is essentially a language
with "if" and "goto". Old gem was I guess a language with "for-each".
If you keep going you eventually start to invent tags like <if>
<while> and so on. In the end I decided that while there is
nothing wrong with configuring scenarios in XML if it solved
a particular set of problems, this idea should not be at the core
of the program because it could never solve everything. So
I abandoned XML while reserving the idea to perhaps bolt
something onto the side somewhere if it made sense later on.
Instead I made the decision that you control the flow with
Java code. If you want something to happen to your email,
you write a bit of Java to do so, and things were modular
enough that it only takes a couple of lines to do most things.
There is even a web page where you can type in your Gemlet/mailet
and it compiles it on the fly and inserts it into the running
server.
I also made the decision to put configuration parameters
into a database. This obviously has its pros and cons, but
one big pro is that it unifies the storage of static and
semi-dynamic parameters. This means for example that given
a Gemlet that can send an email with to,from and subject
parameters it also serves perfectly well as a mailing list
Gemlet and the to or bcc parameter can simply be maintained
by a subscribe gemlet instead of a web config page. You could
regenerate XML I guess, but it might be unwieldy if you
had a few dozen mailing lists with a few thousand members
being regenerated every time someone subscribes.
> I think also there will always need to be a 'goto'-like functionality.
> Specifically, if there's an error in processing... then the message go to
> the error processor.
In gem, if there is an error, you throw an exception.
And you can catch exceptions if it suits your purposes.
I can't figure out how you could do this in James... Given
general purpose Mailet's X and Y, you want to do X
and if that fails do Y. In gem you write a Gemlet "Z"...
try {
execute(X);
} catch (GemException e) {
execute(Y);
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
