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...).
An important point is the following: Subscription are links between
JamesUser and Mailbox : right ?
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 ?
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).
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
