On Tue, Apr 27, 2010 at 10:42 AM, Norman Maurer <nor...@apache.org> wrote: > Hi all, > > after spending some time over the weekend to fix some issues with IMAP > I started to feel its a big "over-designed" ...
i started out with that impression. after digging around i came to the conclusion that IMAP has some annoying requirements... > I think it would be a good think to "simplify" the api a bit to make > it a bit easier to understand. So some points which came to me mind: > > 1) UidChangeTracking: > > Is this really necessary ? It does some kind of caching but I don't > see something else for which its useful. Why not just fire the events > directly with a shared MailboxEventDispatcher which is the same for > all Mailboxes? i'm not convinced it's needed but beware... this is one of the few areas retained from the design before i started reworking. i had hoped to replace it but never really worked out how to do that without crippling performance or breaking IMAP. > 2) Global Mailbox caching > > At the moment the Mailbox is cached in a HashMap. The problem with > this is it will never get recycled by the GC. This can generate a OOM > over long time i run IMAP with approx 1.5G spread over around a hundred mailboxes. i've never had an OOM. so i never bothered changing this. > The other problem with this is, the Mailbox should be "tight" to the > MailboxSession. Let me explain why. For example in JCR we could use > the User/Pass which is bound to the MailboxSession to access different > parts of the JCR Repository etc.. i thought this too originally but i couldn't work out how to do so without cripple performance or breaking IMAP. IIRC these are related issues. the essential function is caching and synchronization. in performances terms, i think much higher performance could be achieved by replacement by something asynchronous and event driven using a blocking queue. this would be a substantial change. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org