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 08:34:07 GMT
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 ;-)

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


View raw message