OK
So AbstractStoreMessageManager doesn't implement MessageMapper (and it
was in your javadoc :)
... and implements Mailbox (the org.apache.james.imap.mailbox.Mailbox,
not the org.apache.james.imap.store.mail.model.Mailbox...)
The org.apache.james.imap.mailbox.Mailbox has much too do with
MaiboxSession and not with domain classes, so it respects your goal.
Maybe the domain independence could be also documented in the javadoc.
Talking about domain model, I'm sometimes a bit confused. We have a nice
package org.apache.james.imap.store.mail.model that contains the model,
but my 2-cents:
- There are a few utils classes (PropertyBuilder,...) that could be
moved somewhere else.
- Document could be renamed to Message (I think we talked about it some
time ago)
- When you read code, Mailbox,... is sometimes confusing because it
exists somewhere else, for example in
org.apache.james.imap.mailbox.Mailbox. This last one has more to do with
"service" than with "domain". I don't have a good name right now, but
Maiboxable seems the closer to what I'm looking for.
Hope I'm not too niggling,
Tks,
Eric
On 20/08/2010 07:36, Norman Maurer wrote:
Let me try to explain it....
The idea is to let the MessageMapper untouched, because its API is
really easy to understand and use. Its not the most Performant todo
but thats the price to pay.
So I introduced a new abstract class which can be used if you want to
write a custom store which is not forced to use a MessageMapper and so
is a good fit for other implementations which not works so well with
the Domain model and lazy loading (nosql for example).
Hope this explains it...
Thx
Norman
2010/8/20, Eric Charles<e...@apache.org>:
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
---------------------------------------------------------------------
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
