Another piece of the puzzle. HBase and JPA use less of the classes from the Store API. Therefore they also extend the managers to provide their custom classes. I'm still not sure why they do that, instead of using for example SimpleMessage.
I found a Couch library that claims to be a lot like JPA. I would study the JPA impl, but maybe there is a good reason to look at HBase instead? I'm not sure how I would do TDD. What to test? Who tests the tester? But maybe TDD will change my way of looking at the code, and proving assumptions. I still find it hard to read Java code that spans more than 5 classes. Pepijn On Sep 23, 2011, at 10:26 PM, Robert Burrell Donkin wrote: > On Fri, Sep 23, 2011 at 12:30 PM, Pepijn de Vos <pepijnde...@yahoo.com> wrote: >> Looking at memory, I see mappers and providers, what do these terms imply? >> >> Now, I would think another mailbox would look similar to this one, because >> they do the same thing, right? > > The mailbox API is an adaption layer abstracting quite different > storage implementations. > >> Looking at jpa, I suddenly see manager classes added to the mix, and in >> general just twice as many classes. Are these part of the mailbox spec, or >> just an artifact of JPA? >> >> It looks like there is a discrepancy to what I think is the responsibility >> of a mailbox, and what the actual responsibilities are. >> >> This is how I would imagine stuff works: >> There are mailbox and message classes which belong to each other. Say >> IMessage and IMailbox. Now I simply implement these interface that have >> methods such as list() and save() >> >> Now the reality seems to be somewhat more involved. I'm not going to look at >> jpa, but for memory it seems like these mapper classes take concrete >> Message, Mailbox and Subscription(?) objects and store them. >> >> There are a lot of seemingly Mailbox related methods on the MessageMapper? >> >> It seems the provider classes are mainly concerned with the Message-ID >> header? >> >> Writing this email cleared up some relations already, but looking at >> anything other than memory, makes me think I'm not even halfway there. > > There are different ways to tackle API implementation. I find it often > takes a long time to understand lots of existing implementations but > if I were to pick one implementation to study, it would be HBase. > > I prefer to dive straight in with TDD: write a test, make it pass, repeat. > > Robert > > --------------------------------------------------------------------- > 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
