> - Restart for every conf change. The container can help with this, as can a refactoring of the process.
- All in XML files (or worse, a database) <<shrug>> This bothers me not at all. > No consensus on how to support more complex processing logic > (matcher params, BSD scripting, etc...) I think we've got some consensus to work on after the next major release. > Looking over the config files for qmail on ASF infrastructure makes you > appreciate the expertise that the ASF has. The large files with rules > to block emails based on subject or attachment patterns is, well, > impressive. Right now James has no manageable way to support this. Huh? I use almost the same files with FileRegexMatcher. Right now that is only handling headers, but I'm considering a substantial change to use the message as a stream, which would (a) remove the need to load the message body, and (b) allow matching body content. > At the same time, we get questions about extracting protocol handlers, > embedding in JBoss or other apps, and otherwise componentizing James. I have no need to do those things. If we want to have an embeddable mailet container, that is another matter. > a. Push towards more developer friendly uses, e.g., embedding in different Avalon containers, w/JBoss, extractable protocol handlers, etc..? Developer friendly, yes. But I don't consider providing extractable code that someone can repurpose to be developer friendly. We should focus on making James better at what it is and can be. Extending and enhancing James, not making it a toolkit for building other servers. > b. Towards more sysadmin friendly uses e.g., scripting in protocol handlers, complex processor logic, etc... Yes to those, as examples of what I think (a) can really facilitate. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]