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