hi, Joachim Draeger schrieb: > 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. > Agree,, Btw the names you listed here sounds good. > 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. > Thats a good point... So we can get sure that its possible to switch from pop3 to imap with existing mailboxes without problems :-) > 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. >
+1 > 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. > How is this notify workin ? what for clients can use such notifys ? > 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. > Is it working better in torgue snapshot or still alpha ? > 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 That all sounds very well.. But at first i whould like to merge your stuff "now" to trunk. Why we should work in the branch if we can do it in the trunk without risks. ? bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
