Hi, comments inline again ;)
2010/8/22 Eric Charles <e...@apache.org>: > See comments after. > Eric > > On 22/08/2010 10:12, Norman Maurer wrote: >>> >>> Which means, not only merge the SubscriptionManager into the >>> MailboxManager like you did, but also the SubscriptionMapper into the >>> MailboxMapper. That would make the separation between .user and .mail >>> superfluous. >>> >>> Does that make sense? Maybe your current attempt is still better, I >>> haven't checked yet. >> >> Yes this makes sense too.. The question is do we want to have an extra >> interface for subscriptions or not ? The problem with the current >> patch is that its not really optimal how the startProcessing... >> stopProcessing is used.. Because the SubscriptionManager does not have >> such methods and so it can lead to leaking resources if the methods in >> MailboxManager is not called.. Thats a problem cause it would be >> possible to use the SubscriptionManager alone.. >> >> If we go backto option 1) we don't have this problems.. >> >> So I'm still not sure what solution is the best .. >> > DefaultProcessorChain is responsible to invoke the MailboxManager and the > SubscriptionManager. > So the behaviour of both is controlled by an external compontent, the > DefaultProcessorChain (they are coordinated/controlled by something). > But it's true that SubscriptionManager could be used independently of > MailboxManager, and one depending on the other, this could produce unwanted > effects (didn't look which one...). I don't see any side effects here.. > > An important point is the following: Subscription are links between > JamesUser and Mailbox : right ? Not 100%.. Subscriptions links users to Mailboxes. The users are just Strings and nothing more. So its not coupled to james server in any way. > We are in a "mind" to let the James Admin user configure the way he want to > persist its mails, its users,.. > Let's take the example of JCR mailbox store with a JPA user store. Where > would the subscription be persisted : JCR or JPA ? If we go with 1) its JCR, if we go with 2) its up to the admin. > And why the user wouldn't be allowed to persist its subscriptions in (I take > any example) : another DB, a LDAP, a noSQL store,... > If we think we should give freedom and tools to 3rd party to persist where > they want the different James domain aspects, leaving the aspects separated > in different is not a bad thing. > > If we think that a Subscription management is on the same level as Mailbox > Management (seen from here, it seems), we could also add the start/stop > processing and addListerner methods on it (it can always be useful to be > notified of a subscription). true enough Just as a side-note... For example the subscription stuff is not really necessary for using MailboxManager in non-imap enviroments (for example pop3). Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
