james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer ...@byteaction.de>
Subject Re: Notes from ApacheCon
Date Mon, 03 Jul 2006 04:43:28 GMT
Am Sonntag, den 02.07.2006, 17:23 -0400 schrieb Noel J. Bergman:
> 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.

Right.. I nearly finished it. Just Junit tests to fix. The rest should
be ok. Only some cleanup should be done now and dedicide in which
packages the classes should be placed. Any idea? 
Feedback and review very welcome :-)
 
> 
> 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.
> 
Just a quick note.. We agreed that we should build some "generic"
classes for clamav and spamassian which can be used from smtphandler
chain (onMessage) , mailet and machter. 
Whouldn'T it be cool to reject virus emails  and spam in smtp
session ;-)

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

If i remember right Stefano was talk about some SMTPHandler which was
done with MINA before.. Stefano im right ?

> 
> 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 agreed all that we should cleanup and split the config.xml.

> 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.
They also told us that it should be no problem to do clustering with
derby 10.1.2.1!

> 
> 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.
Maybe we should ship one basic config.xml and one advanced ?

> 
> 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.
Right .. We also talked about some release schedule ( If i remember
correctly). I hope we can push out a release every 6 Month . Bugfix
releases can be made if needed any time!

> 
> 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.
Some reason of this thought was that we agreed ( At least Noel and me ..
not sure the others too :-( ) that a mailserver should not give to much
attention on bad formated emails.. Other mailserver send emails which
make problems with javamail without probs (qmail,postfix etc..). An
other problem seems also the memory usage of javamail! The use of
Streams should speed up things

> 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.
Ok i will change the default in 2.3 to file ( If it not was allready).

> 
> 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.
Thx to Alan for post the right command: "mvn ant: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).  :-)
Thx Noel .. I will have a look but i think i remember all correctly in
my code which i commited before :-)

> 
> Cheers for now.  :-)
> 
> 	--- Noel
> 

One think that i remember is that we (Noel and me) spoke about a LMTP
interface to support more filters. Not sure yet if that of intresst now.
Anyway we should remember it.

Bye 
Norman


Mime
View raw message