james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: James - GEM
Date Tue, 23 Oct 2001 11:44:14 GMT
On Mon, 22 Oct 2001 23:28, Chris wrote:
> Of course, having developed my own product
> with it's own strengths, there are some things
> that concern me about James' design. Not wanting
> to be critical, but to point out what I see
> so far...

Feel free to be critical - it is the one of the best ways that something can 
be improved ;)

> * 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". No doubt it works ok for many simple
> tasks but it doesn't take too much imagination
> to imagine a message bouncing around in some
> confusing fashion between a number of different
> states... or being quite hard to program
> a complex set of logic.

Right. I think that there is better ways of doing the control transferal. I 
actually implementerd an API similar to Mailets last year with a few 
differences. 

Last time I checked James did not handle the "envelope" data to my liking. 
For instance if there was one mail that had 3 "RCPT TO:" it would still only 
go through the mailets once. I would prefer that the mail went through 3 
times with 1 "RCPT TO" per pass. Combine this with a GOTO "mailet chain" (or 
COPY onto mailet chain) and you get most functionality.

> * It's not clear to me how you would pass
> configuration parameters to another mailet
> at run-time. e.g. Let's say you had a mailet
> that ftped any attachments to a particular
> server. Let's say another mailet wanted to
> call the ftp mailet and tell it drop the files
> in a directory corresponding to the current
> date. How to pass date as "directory"
> parameter to ftp mailet?

Well I would like to see arbitrary "session" data stored with the mail. 
Currently there is room for some data but it is all hard coded and it would 
be interesting to stuff the mail object with extra data that could sorta act 
as a parameter passing system ... though I am not sure that calling other 
mailets in this way is appropriate. Why not just use a normal java bean to do 
the work ?

> * 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 in the
> code. I would have thought you may want to store
> differently depending on say which mailbox you
> want to store it in for example.

good point. However with a decent mailet system you should be able to store 
in either. The spool would however still be stored in the global format.

> * I'm wondering, it looks like the XML design
> of random config parameters probably prevents
> specifying a valid DTD. In my experience this
> tends to be a bad thing.

You can't specify a DTD but yoou can specify an XSchema ;)

-- 
Cheers,

Pete

When a stupid man is doing something he's ashamed of, he always 
declares that it is his duty.
					 George Bernard Shaw 


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


Mime
View raw message