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