On 8/10/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > > On 8/10/07, Zsombor <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > Finally i've been able to run James with the Spring container, it's a > much > > simpler environment for me to develop. > > cool > > > My plan is to write a > > Hibernate/Spring based IMAP backend, with a 'dbfile' and pure 'db' > > semantics. I will happily share it (contribute it), if someone > interested > > when it's finished. > > interested, yes > > there are unresolved policy questions about code with LGPL > dependencies at apache ATM but i hope that these will be resolved > before the end of the year. even if these aren't resolved in time, > it's be great if you'd either grant a license to apache for eventual > inclusion or start a project offshore (googlecode is pretty good). > > an alternative strategy would be to indirectly create a hibernate > implementation via JPA. apache has a good JDO backed JPA > implementation. at most, the hibernate specific deployment would have > to be kept offshore but the vast majority of the code could be > committed to JAMES right away.
Ok, i will look into the OpenJPA. Currently I dont use too much hibernate/spring specific things. Just some javax.ejb annotations, the spring @Transactional annotation, so I hope the same logic works for the pure JPA solutions. (i'm interested in JDO and would be much more likely to contribute to > a OpenJPA implementation than to a plain hibernate one. the OpenJPA > team is also very friendly so i'm sure that they'd be happy to help > out with architecture.) > > > I have some question about the current IMAP code in the trunk. I know > it's > > highly experimental code, and never released, but I'm curious to ask > that do > > you think that the current API with the > > MailboxManagerProvider/MailboxManager/ImapMailboxSession will see > > revolutionary, or evolutionary changes ? I mean, that do you plan to > rewrite > > it from scratch, or only minor method additions/deletions will occur? I > > know, you cant promise anything, but I dont want to waste my time, if > > someone totally rewrote the backend interface in the last few days, and > > intends to commit it in the near future :) > > (i had it mind to move the mailbox code out from core into it's own > module. we've also talked about renaming some of the interfaces. i'll > start a thread on this today.) > > i've given up trying to make IMAP perform with the torque mailbox > implementation. this is partly down to an inefficient table structure > but mostly down to inefficiencies baked into the API (common IMAP > operations take numerous database calls to execute and bulky message > data is too often fetched). What do you think, which operations is the most common ones? Currently I'm trying to figure out what is the main difference between the UID, MSN and KEY value, which is unique to the mailbox, and which to the whole repository. My main concern of the current torque backend is that it's currently try to check the modifications in-VM, and deliver the notification synchronously, instead of a polling db-thread, which i think should be better. (So multiple IMAP frontends can be deployed for one backend database). i'm interested in JCP backends (rather than DB) so i no plans to fix > these problems. my plan for the experimental code is to introduce a > new API and provide an adapter for the mailbox API (rather than > rewrite it). i hope that this would allow mailbox implementations > which wish to optimise themselves for IMAP would be able to do so but > a slow but working IMAP would be possible even with a plain > implementation. > > that isn't to say that the mailbox API is fixed. it's in need of a > review. there's a lot of unintuitive naming and lots is not javadoc'd. > i suspect that you'll find as you implement that you'll find issues > and inefficiencies. Yeah, i found some. For example the getMailboxManager(user).createInbox(user) call. Or something like that. creating a second implementation allows triangulation. the is the best > way of reviewing and perfecting an API. if you're going to be around > on list, then it would be great if you'd help to evolve this > interface. please also free to post constructive criticisms of the > mailbox API as you implement (either in JIRA or on list). > > - robert > I will do that, when I will finish my implementation / and my holiday :) BR, Zsombor
