Hi Norman,

I applied the last uploaded file (proposal_v3.diff):

- patch works, which is good :)

- I don't see any change on MessageMapper. Probably the modif to return only uid was already committed (IMAP-203,...) ?

- You migrated methods from StoreMessageManager to AbstractMessageMapper. So now, I'm a bit confused about the class "responsiblity". Could you summary us the "roles/responsibilities" of these 2 classes. That will help to define which methods goes where...

- Abstract/extend is widely used in james. I sometimes force myself to thin to "favor composition over inheritance". Did you consider composition instead of AbstractMessageMapper ? (maybe stupid question and I should have tried to implement before asking... :) Of course, you can find plenty of discussions and explanations (http://www.google.com/search?q=favor+composition+over+inheritance) on the net

- I like the new UpdatedFlag class. When you read it, you understand what it is aimed for. Separating "data domain" from "service domain" is always good.

Tks,

Eric



On 08/19/2010 12:20 PM, Norman Maurer wrote:
Hi there,

I' currently looking for ways to make it easier to create high
performant Mailbox implementations while reusing the store api. I
think there are some things we should change to allow this.

* We should return only the uid of the message if nothing more is needed
* We should move some stuff to an abstract MessageMapper
implementation to make it easier to override and handle it different
and still be able to use the store api.

For this I opened a jira and attached a patch whic hshows the idea..
I'm still not 100% sure if its really a good idea, so feedback is
welcome :)

https://issues.apache.org/jira/browse/IMAP-202

Bye,
Norman

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to