All criticism welcome. comments below. ----- Original Message ----- From: "Chris" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 22, 2001 9:28 AM Subject: Re: James - GEM
> 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 > in. Great! We always like more developers, especially someone with experience building much of this. > * 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. 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. 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. Similarly you may do numerous tests and want to be able to send a message to the spam processor at any point. I think separate processors is fine... just get something more advanced than the LinearProcessor. > * 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? I agree with Peter about the "session" like behavior... effectively add to our Mail object: public Object getAttribute(String key); and public void setAttribute(String key, Object value); This isn't very difficult and would be some great functionality, but then we'd need a migration plan for mail repositories, which we've pretty much been able to avoid to date. Also with session handling, we could avoid possible race conditions you mentioned by detecting when messages were re-entering processors. > * 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. I think the current setup works fine for the basic user mailbox concept that's supported, but two initiatives (virtual host support and IMAP) will likely add this functionality as part of improving our mailbox concept. Would also be nice to support quotas and other advanced mailbox features... > * Apart from user names (UserRepository), I can't > see a generalised method for storing dynamic > configuration (e.g. Mailing list preferences). My view is that the mailets that come with JAMES (such as the excellent Redirect mailet that Danny just added) should provide basic functionality from config.xml parameters, yet make it very easy to extend so developers can readily customize. Configuration can be so varied, I like our approach of making it easy to tweak over standardizing dynamic configuration, which may not fit a large number of installations. Also, Avalon was recently upgraded to support configuration reloading, so hopefully soon we can have changes to config.xml automatically reloading and taking effect. > * 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. I agree it's not perfect, but I'd hate to see that config.xml in a properties or other text format... it probably needs to get broken down into smaller chunks, but still... what's the alternative? > Anyway, hope these criticisms are taken in good > spirit, and interested in how you guys see > things. You've definitely nailed some issues we've wrestled with for a long time. Serge Knystautas Loki Technologies - Unstoppable Websites http://www.lokitech.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
