On Dec 10, 2007 3:05 PM, Chris Rose <[EMAIL PROTECTED]> wrote: > 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.
easiest way would be to create an custom implementation of the MailboxAPI > 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) take a look at the interfaces in http://svn.apache.org/repos/asf/james/server/trunk/user-api/ most likely, a new implementation of UserRepository should be enough > >>> 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+? TBD 3.0 is a long way off. milestones may ship sometime in Q1. Zsomber prefers the older implementation. i'm working on the newer one. both or nether may ship depending on developer activity. if a stable, mature implementation is completed before 3.0 then it may be backported to the 2.x codebase. > >> 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. it's expressive enough there are quite a number of developers who are unhappy with it's current form. i've stripped a lot of complexity away over the last fwe weeks but there's more still to do. you'd need to follow the list in detail to avoid unnecessary work since the API is likely to be a moving target. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
