Hi Norman,
The following hierarchy is obvious and gives services such as create,
login, logout, search on *mailboxes*:
MailboxManager (interface)
/|\
|
DelegatingMailboxManagerimpl (abstract)
/|\
|
StoreMailboxManager (abstract)
/|\
|
JPA/JCR/Maildir/...MailboxManager (concrete)
This one gives services to append, set flags', expunge on *messages*:
Mailbox (interface)
/|\
|
AbstractStoreMessageManager<Id> (abstract)
/|\
|
StoreMessageManager<Id> (abstract)
/|\
|
JPA/JCR/Maildir/...MessageManager (concrete)
Wouldn't that Mailbox interface finally be named MessageManager ?
But np for me to live with the existing names.
Will StoreMessageManager remain abstract (it is in the patch) ? (if yes,
we will end up with a AbstractStoreMessageManager and a
StoreMessageManager, both abstract,...).
I suppose the criteria to implement in AbstractStoreMessageManager was
'no need for messageMapper'. Is there a common characteristic to these
methods (so we can QualifyStoreMessageManager) ?
If I understand well, store implementors could reuse or simply override
methods of *StoreMessageManager.
I was also talking about composition, so a store implementator would
know directly which methods he should implement to take control on a
certain behaviour aspect.
With the inheritance mecanism, the implementator has to go "deep" in the
class hierarchy to know it.
Would you rename Document to Message in IMAP-202 ?
(btw, in my first reply, I confused somewhere ...Mapper with ...Manager,
sorry)
Tks,
Eric
On 20/08/2010 12:07, Norman Maurer wrote:
Comments inline..
2010/8/20 Eric Charles<e...@apache.org>:
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...)
yep ..
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.
Fair enough..
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.
I see no value here..
- Document could be renamed to Message (I think we talked about it some time
ago)
+1
- 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.
Thats why its still called Mailbox ;)
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
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
