james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Notes from ApacheCon
Date Mon, 03 Jul 2006 08:20:52 GMT
Norman Maurer wrote:
> 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 :-)

Not sure I'll find the time soon, but I would like to put my hands in 
there. Would you mind if I work directly on "your" branch to show how I 
would like to have it?

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

In svn there is a almost working implementation made by Mike Heath.
Mike is a committer to James and his work is licensed as ASL2, I think 
he would be happy to grant apache the rights to include his code back to 

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

The Phoenix we currently use should support component configurations and 
configuration merging:
@see FileSystemPersistentConfigurationRepository

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

If you never call operations that try to access or modify the message 
source the current MimeMessageWrapper avoid any parsing of the message.
If anyone want to implement a Mime4J parser that build the internal 
MimeMessage structure we could skip the parsing provided by MimeMessage 
easily (this is not a simple task and need much time).

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

We also did that for jspf.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message