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
