Ok so my current toughts are: * Use one MailboxMapper/MessageMapper/SubscriptionMapper per request. Which in fact should share the same JCR Session / EntityManager etc. a request should be handled by a "new" thread so we would have a ThreaLocal like pattern. The instance should get stored in the MailboxSession while processing the request.
* Dispose the MailboxMapper/MessageMapper after each request to be sure that the underlying Entitymanager/JCR Session get closed. If we would close it before we could get into trouble when lazy load stuff etc. Does this sound good ? Bye, Norman 2010/5/5 Robert Burrell Donkin <[email protected]>: > On Wed, May 5, 2010 at 12:52 PM, Norman Maurer > <[email protected]> wrote: > > <snip> > >>>> Would it be worth discussing where James IMAP is going in the near-term >>>> and whether we should coordinate. >>>> >>> >>> You are totally right. I'd be glad if we could find a good design for IMAP >>> and implement it as soon as possible, not least because my maildir >>> implementation will be affected by this process. > > IMAP is a subtle protocol. designs are non-trivial. > >>> I'd like to build on a relatively stable structure. > > use an internal API, then any changes can be bridged. a good > commons-style Maildir library would be really useful generally and > much easier to debug. so that's where i'd start. > >>> That would, by the way, be my only objection to >>> releasing James too soon. First we should stabilize the IMAP stuff. > > release often, release early ;-) > > better to ship something with a low version number > >> Me too. I did a lot of refactoring over the last weeks and sometimes I >> feel like just turning cycles.. > > +1 > > always seemed like that to me as well... > >> I the long term I would like to see >> some kind of async processing for mailboxes. But I think thats not >> feasible in the short term. > > dunno > > the reworking i did always had async in mind. last time i looked, > should be reasonably easy to flip into the message passing paradigm... > > - robert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
