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 10:02:36 GMT
Am Montag, den 03.07.2006, 10:34 +0200 schrieb Norman Maurer:
> Am Montag, den 03.07.2006, 10:20 +0200 schrieb Stefano Bagnara:
> > 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?
> I have no porblems with it but whould also hear what the others think
> about the "current versions" and what to do for improve it . We can also
> revert it if we want keep it otherwise ;-)
> 
> > 
> > >> 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 ?
> > 
> > http://hausmail.safehaus.org/
> > 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 
> > james.
> Thx for the link.. I knew i remember right ;-)

Anyway minas SSL support need java 1.5. But i think this will be no
problem for 3.0. Java 1.5 should be release until we finish the 3.0
release. Any thoughts ?

> 
> > 
> > >> 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
> > http://mail-archives.apache.org/mod_mbox/avalon-phoenix-dev/200207.mbox/%3C200207161433.51290.proyal@apache.org%3E
> > 
> > >> 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.
> > 
> > Stefano
> 
> 

bye
Norman

Mime
View raw message