On 10/25/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > On 10/25/07, Zsombor <[EMAIL PROTECTED]> wrote: > > Hi, > > hi Zsombor > > > Does anyone have time and knowledge, to merge my patches against the > IMAP > > server part. > > definitely > > (the timing's good since i planned to start taking a look at some of > this tomorrow)
Great :-) > I'm currently working on a MINA based protocol handler, when it > > can handle starttls I will post it for merging too. > > sound great :-) > > i'm hoping to get back to this area soon so it'd be good if you could > start posting design ideas and intermediary patches to JIRA so that we > don't start treading on each others toes. > > > So my current pending patches are here: > > https://issues.apache.org/jira/browse/JAMES-806 > > https://issues.apache.org/jira/browse/JAMES-807 > > https://issues.apache.org/jira/browse/JAMES-808 > > cool > > i also have some stuff locally which needs to be committed into trunk > so if you could let us all know what you're working on then we'll > avoid treading too hard on each others toes. > > i made a performance break through on my local fork a couple of weeks > ago. using MimeMessage is *very* slow (as well as being inaccurate) > and is unnecessary. i'm now well on the way to having a performant and > accurate FETCH implementation. needs some more testing but i'll push > what i have into trunk. some of this uses Mime4J so i need to push > forward some work on that. I've done any performance test, but in the JAMES-808 i've made some interface change to allow skipping the creation of MimeMessage, with caching if the backend supports it. My hibernate based backend works, and the code is accessible here: http://james-imap-storage.googlecode.com/svn/trunk/james-imap-storage/, however i've only run it inside my eclipse, so it's very experimental. My MINA connector is here, http://james-imap-storage.googlecode.com/svn/trunk/imap-mina/ currently doesn't handle literals too well, but I know how to fix it. For the MINA based connector there is some other patches pending, which introduce some new interface instead of the hardcoded implementations, I will post it at the weekend, I hope so. BR, Zsombor indexing is also important: the vanilla does too many table scans. > i've been running this on my local fork for a while now with good > results. i'll start moving this into trunk. > > - robert >
