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/[EMAIL > > PROTECTED] > > > > >> 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
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
