Zsombor wrote: > On Dec 9, 2007 9:20 PM, Robert Burrell Donkin <[EMAIL PROTECTED]> > wrote: > >> On Dec 9, 2007 6:58 PM, Chris Rose <[EMAIL PROTECTED]> wrote: >>> I'd like to investigate extending the James IMAP implementation to use >>> alternative message stores. I've looked into the 3.0 code to gauge the >>> plausibility of this and what I see out of the gate is not >>> encouraging... but I'm unfamiliar with the codebase, so all is not lost. >> >> what type of message store did you have in mind?
What I have in mind is this: Our company develops a custom document store for a correspondence engine, based on Hibernate and loosely modeled around an existing IMAP server, so the gap between our implementation and an IMAP mailbox store would be small. I'd like to use James as a front-end to our store in deployments of the product, which means I need to tell James to use our document store in place of whatever the 'standard' imap store uses. The biggest impact this has outside of the mail store itself is that we also have our own concepts of "users" which means that to some extent I'd have to replace the user repository, too. That may not be as possible, but I don't know the James code well enough to say. (I just started looking at it yesterday) >>> Is there a place I'm missing where I can map IMAP commands to an >>> alterate message store? >> i'm a little uncertain about what you precisely mean by mapping >> >> the SEDA implementation (under active development) has decoupled >> decoding, processing and encoding layers. the processors map request >> objects into response object. if this is what you mean than it's >> possible to insert alternative processors into the command processing >> chain. So, can I take away from this that the SEDA implementation is the way to go, and the imap-* modules are... what? Which parts of that code are going to end up in 3.0+? >> however, IMAP is a nasty protocol. you may find it easier just to >> create an alternative implementation of the mailbox API. (if he's >> around, Zsombor may want to jump in here since he's ported the torque >> based implementation to hibernate.) >> >> the mailbox API is being revised ATM. hopefully, these changes should >> make implementation easier but until they're finished, the API will be >> a moving target. (noel may want to jump in to describe some of changes >> being mooted.) >> >>> Would this be a useful extension to make >>> public, if I were to pursue this? >> there's a lot of interest in this topic. Zsombor has a hibernate port. >> i'm more interested in JCR backed solution than RDBs. but IMHO it's >> important to have a complete, tested and debugged implementation. IMAP >> is currently incomplete and under active development. the mailbox API >> is also under active development. so, you'll probably either need to >> work closely with us or fork. I'd prefer the former, obviously; I'm not interested in maintaining the server proper, just in ensuring that the IMAP mailstore API is sufficiently expressive to allow an alternate store to be provided. >> - robert >> >> > > > Yes, I'm here, unfortunately recently I dont have too much time to > contribute, so my Hibernate backend is not uptodate to the recent API > changes, but you can access it here: > http://code.google.com/p/james-imap-storage/ Thanks, I'll look into that; We currently have a hibernate-based API for our document store, so one hopes that the gap there is small. > BR, > Zsombor > -- Chris Rose Developer Planet Consulting Group (780) 577-8433 [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
