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 Notes from ApacheCon
Date Sun, 02 Jul 2006 21:23:32 GMT
Very quick, since I need to get up at O'Dark:30, and may not be online
before Thursday.

Danny, Norman, Vincenzo and I met.  Good chats.

Norman and I probably spent the most "quality" time -- from a JAMES
perspective -- working on code together.  Some of the results are what he is
coding into the sandbox.  More to follow.

Vincenzo has some cool ideas for AV, Bayesian and signed messages, but I'll
let him explain.  Robert Burrel Donkin may want to collaborate with us on
PGP.  We can add PGP-signed message support to our current S/MIME handling.
Cliff Schmidt will help us deal with the legal filings.

Spoke with Peter Royal.  He'll help get us moved to MINA.  We looked at the
current JAMES code.  As many of you may recall, Peter is an ex-Avalon
contributor, and knows both sides of the situation.

Danny and I both spoke with the OSGi folks.  They'll help.

Danny and I concur that we should probably create our own
o.a.mailet.configuration package, modeled on Jakarta Commons Comfiguration
with an interface we can use and keep constant, and map that onto Commons
Configuration.  Danny's argument, which I accept, is that we want control
over the interface, and can't rely upon Jakarta Commons not to change it.  I
also reviewed with the Jakarta Commons Configuration with the OSGi folks,
and I believe that we agree that it would be the right direction for JAMES.

We also spoke with the Derby folks, and got some tips from them, which will
result in some changes for the database schema.  Also, they have a new
release coming out with in a week or so, and that would be a good time to
put out a release candidate.

Norman and I reviewed v2.2-v2.3 updates, and agree that we can put in a
default chain, although it will mimic v2.2, i.e., no fast-fail, so our new
config.xml should still define a chain, albeit with docs that the chain
configuration WILL CHANGE for future releases.

Roadmap-wise, I believe that we feel that once we're done with v2.3, the
next release will be v3.  It will include the new fast-fail code, database
changes (which force the major version jump), likely Stefano's refactored
FetchMail (just needs to be reviewed and tested), and some other changes.
I'm tired, and don't recall what there were others on the list, but we're
not talking pervasive, radical, changes.  We agree that we want to keep
moving AND releasing.

Concurrent, or after, would be moving to MINA, OSGi and the new spool
approach, and that would probably be v4.  I believe that we currently do not
want to base message storage on JavaMail, and we should start to shift
things to MIME4J when appropriate.

As an aside, I believe that we agreed that database is preferable for
everything except those things for which we use ToRepository, e.g., Spam,
Error and AntiVirus folders.  The reason being that the file system
repository is much easier for admins to monitor, review and purge; whereas
the database is nicer for spooler and user mailboxes.  So we can go that
route for v2.3.  I still prefer dbfile, but the changes to the db schema in
v3 will address much of my preference for dbfile.

I spoke with Jason van Zyl, and although I prefer that we continue to use
Ant rather than Maven, for interim use when necessary, we can compromise by
agreeing to use the `maven ant` command and maintaining the resulting
build.xml file in svn for any JAMES project that uses maven.  That command
must be run, and the resulting file updated in svn, whenever the project's
pom.xml changes.  That will allow anyone to build the project using just
Ant.

That's all for now.  More later, and others should respond with what they
remember, and correct me on anything that I mis-represented or forgot.

Speaking of which, attached are notes for Norman which need explanation, are
inconsistent (the same class name spelled three different ways) and
incomplete, but he'll understand (and so should most forgiving readers from
context).  :-)

Cheers for now.  :-)

	--- Noel


Mime
View raw message