james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris <ch...@bitmead.com>
Subject Re: James - GEM
Date Mon, 22 Oct 2001 13:28:00 GMT

Ok, I've been reading the James code and I've
nutted out how it works. There's obviously
tons of great stuff, great abstractions and
neat ideas in James. I'm interested in joining

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...

* 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.

* 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?

* 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.

* Apart from user names (UserRepository), I can't
see a generalised method for storing dynamic
configuration (e.g. Mailing list preferences).

* 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.

Anyway, hope these criticisms are taken in good
spirit, and interested in how you guys see

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

View raw message