hi! First of all Mailboxmanager is a working title. I decided not to use "repository" because I wanted to make clear that it is much different from the current MailRepository. At the moment I would prefer MailboxService for MailboxManagerProvider, and MailboxServiceSession for MailboxManager. :-) But we should decide on the naming when the API is done and the final function is known.
API Maybe you noticed there are many packages and many interfaces. I tried to categorize and subdivide the functionality. The idea is to allow implementations to fulfill different levels of requirements. (Imap: everything is needed, POP3 only: less) Probably some of them are superfluous or could be recombined. BasicMailbox To find a compromise of the "too complicated" discussion I created BasicMailbox and BasicMailboxManager. Well, they are needless for imap but fit well to other James services and could be at least a candidate for upcoming MessageRepository. :-) Creating a wrapper to GeneralMailbox would be easy and would hide the complexity. SessionWrapper They do belong to the implementation but could be shared by different backends. The goal is message number stability which is needed by Imap, Pop3 and JavaMail. That means that the message number have to be stable even when a message gets deleted. Renumbering is allowed only when the client could be notified. And that should work on a backend that is accessed by different hosts. The service has to react to what it finds on the DB. To be able to deliver the required events it has to keep track of what the client is aware and cache the known message uids. This is done in the tracker package. Together with the number stability the tracker and cache are really work in progress. Even worse: I didn't know where to go when I started them. :-) Heavy rewriting/refactoring is needed here. But that should be done when the API is some kind of finished. Until then it should considered as a prototype. Torquebackend The goal I had in mind was allowing access to the DB by multiple hosts and let the DB manage the locking. Same here. Not everything that had to, already uses a transaction etc... I have many ideas how to make it water-tight, but... API first! :-) Unfortunately I noticed that derby support is only alpha in Torque 3.2. One problem that exists that a db generated key can't be fetched. Maybe we could use a custom build until 3.2.1 is out. Roadmap I stopped working on the number/cache/tracker/torque stuff because I think that we should work on the API now. In the current state it would be possible to react to substantial API changes. Even if the API and the implementation had to be rewritten from scratch we could use the existing stuff for reference. As a next step I plan to explain the current architecture and the ideas and intents I had in mind. greetings, Joachim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
