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
