New JavaMail

[acoliver]

This: http://jcp.org/aboutJava/communityprocess/maintenance/jsr919/JavaMail-1.4-changes.txt

does indeed look a great deal better (as scott pointed out today). Does this resolve enough of our issues with mime parsing/streaming/etc? (I'm not yet sure about the synchronization ala JAF)...

I'm knee deep in M3 release stuff (filed new bugs, discovered a missing but essential features, wiki pages, doco). M3-RC1 is expected tomorrow.

-Andy

[mikezzz]

I need to sit down and look at how the MimePartDataSource and the ContentInputStream components work. It would be nice to provide a memory efficient JavaMail interface backed by the stream store. Even if we replace JavaMail some third party components may prefer the JavaMail API. jASEN for spam filtering springs to mind.

Mike.

[acoliver]

One thing is it seems like JM still uses JAF which totally synchronizes things all to hell. We may need to embrace and extend.

[raffaeleguidi]

Did you hear about "Ristretto", the JavaMail replacement from the columba mail client project (http://columba.sourceforge.net/)? It looks a viable alternative to JavaMail.

[mikezzz]

Nice spot!! Looks quite good. Bit closer to the metal which would be useful for us. You can actually get the error codes back from failed request, can't do that in JavaMail. The data() method appears to take an input stream which will play nice with our streaming API.

Mike.

[acoliver]

If it will work then we can use it, it is MPL. I'd be happy about it too because we can actually fix any performance issues instead of petitioning some spec committee.

[mikezzz]

I am going to have a look at it for M4 when I try to fix JBMAIL-105.

[raffaeleguidi]

I knew you would have liked it ;)