james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@thought.co.uk>
Subject RE: James - GEM
Date Mon, 22 Oct 2001 14:21:09 GMT

> * The means of transferring control between
> Mailets of setting the state to a new processor
> name seems to me to be a glorified form of
> "goto".

I think it *is* a goto, and works in the simple cases.

I don't see why your logic shouldn't be contained in a set of classes which
have nothing to do with mailets, and a mailet used to pass mails to your
process, and send results back to James. That way you could programme as
complex a set of tasks as you wanted to.
Think of the mailet as an event handler handling a specific mail "event" you
can raise new events, let the event propogate, stop the event propogating,
or ignore using events altogether and run some code.

> * It's not clear to me how you would pass
> configuration parameters to another mailet
> at run-time.

Why would the mailets want to communicate? I don't think your example really
explains that, are you saying that you think one mail should be able to
infuence the handling of other mails? If so why not have a single mailet
which could recieve commands as well as process mails.

> * It looks to me like the decision to use database
> or file system to store mails is a decision
> that is made at the very highest level

If you want to handle mail in different ways for different users you'd use
mailets, if you want that kind of control over local mail delivery write an
alternative LocalDelivery mailet.

> * I'm wondering, it looks like the XML design
> of random config parameters probably prevents
> specifying a valid DTD.

This is Alpha code, it is probably possible to have a DTD covering the
existing situation, but it would have to be maintained, and if it was
published it would leave no room for mailet authors to add new parameters,
and comply with the DTD.
Alternatively it'd have to be be so loose as to offer scant benefit.

How would you deal with the issues you raise?

all just MHO, danny.

To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

View raw message