james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Future direction for James
Date Wed, 12 Nov 2003 21:15:21 GMT
> - 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message