2011/10/4 Pepijn de Vos <pepijnde...@yahoo.com>: > 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?
There are a couple of things that a mailbox implementation must do, but it's main job is to store messages in mailboxes and provide a way for the user to retrieve them back. The main "components" that you must be aware in a mailbox implementation are: 1. Mailboxes - they are similar to file-system folders and are used to group together related messages. 2. Messages - must belong to a mailbox (default is INBOX) and have some interesting properties (unique UIDs, they are immutable, they have properties and flags). Much of this information is defined in specific RFC's (Mail RFC, IMAP RFC, MIME RFC). 3. Subscription - the best way I can explain this is that you can subscribe to mailboxes (other than you own - like news, etc; See IMAP RFC). When you connect to receive mails, you will be notified for messages that arrive to your subscribed mailboxes. the Store is a generic framework and each Mailbox implementation must provide the means to save the information on disk. The JPA implementation for example uses object relational mapping to map a Java class to a relational table in a RDBMS. Check out http://svn.apache.org/repos/asf/james/mailbox/trunk/jpa/src/main/java/org/apache/james/mailbox/jpa/mail/model/JPAMailbox.java to see how JPAMailbox class uses annotations to map fields to table columns. That's why you can't use SimpleMessage, because OpenJPA would not know how to save what field to what column. The Hbase implementation is more suitable for you to learn because it explicitly saves/retrieves content to HBase, whereas in JPA you will see a lot of annotations but the actual persistence is hidden. In order to build an implementation I suggest you start by implementing the tests which will initially fail and then try to make the failing tests pass one by one. This is the way I started and it was clear. I also suggest you start by implementing SubscriptionManager and MailboxManager first. MessageMannager and Message related classes are harder. The API is pretty good so most of the work will be to implement the *Mapper classes. Other than that you should probably do very little work say for Managers. A word about the mappers: They are three of them: SubscriptionMapper, MailboxMapper and MessageMapper. They are defined as interfaces (please have a look at those interfaces) and provide CRUD (creat, read, update, delete) for subscriptions, mailboxes and messages. They are used by *Managers to do work in the Mailbox (NOTE: be aware that mailbox has many meanings: the actual store for your emails (e.g. Apache Mailbox), one folder for storing emails, etc. see http://en.wikipedia.org/wiki/Email_box ). Mappers provide simple operations that are used by Managers and beyond to do complex stuff. For example when a user reads a new message, the server must perform some of the following: - access the mailbox - find the message - read the message - update it's flags: UNREAD and maybe RECENT flag - etc. So a user reading a message is a complex operation that spans multiple simple opperations provided by Mapper implementations (see updateFlags, findMessage, findMailbox, etc). > 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. Try reading a book and most importantly: do exercises. Doing is the only way to get better at stuff. I hope that you have a better understanding now and I wish you good luck. Don't hesitate if you have other questions. I will try to answer as much as my time aloes me. Bye, -- Ioan Eugen Stan http://ieugen.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
