Back again.
In DefaultProcessorChain, we know have
createDefaultChain(chainEndProcessor, mailboxManager,
subscriptionManager, statusResponseFactory)
so mailbox and subscription can be seen on the same level, each playing
role in the different processors.
There are now 3 options:
1.- composition/stragety was the initial situation (before the pach)
2.- inheritance was the intermediate commit
3.- chain or responsibility (in the processor) is the current commit.
I like the 3rd one.
Tks,
Eric
On 22/08/2010 08:53, Eric Charles wrote:
Hi,
So Tim, you was also ok with optin 2 and finally Norman reverted to
option 1 ? (not sure to be in line :) ?)
I've looked at revision 987821:
- SubscriptionManager is not used anymore in MailboxManager hirerachy
(StoreMailboxManager,...)
- The 3 delegate methods present in DelegatingMailboxManager are
removed (so, yes, DelegatingMailboxManager is not delegating anymore,
and we could rename it :), or merge with StoreMailboxManager
- The ImapProcess is now responsible for the SubscriptionManager
I suppose the spring-beans.xml is not committed according to these
changes (imapProcessor and mailboxmanager constructors should be updated)
I like the idea to leave an interface thats clearly describe the
Subscription methods.
Is there a particular reason to have now the
DefaultImapProcessorFactory responsible for the SubscriptionManager ?
I can see it's // with the MailboxManager.
NioImapServer finally uses the imapProcessor bean.
btw, if we talk Gof patterns, we went from a "Strategy" pattern to a
"Chain of responsibility" pattern.
So the question I'm wondering is "is it the responsibility of the the
NioImapServer to process the mailbox, then the subscription" (it does
it via the DefaultProcessorChain).
I remain in favour of "strategy or chain", rather then inheritance.
Tim, are the mapper considerations your're talking here related to
IMAP-206 ? (not sure to understand the relations, maybe a separate
thread would help)
Tks,
Eric
On 21/08/2010 22:53, Tim-Christian Mundt wrote:
Norman,
I have not yet reviewed your recent commit. However, I'd like to remark
that I was in favor of your last attempt. I just wanted to
_additionally_:
I think we should also merge them which
would also simplify the package structure because we wouldn't need
the .mail and .user packages anymore.
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.
Best
Tim
Am Samstag, den 21.08.2010, 22:08 +0200 schrieb Norman Maurer:
Ok another attempt was made.. please review changes made in revision
987821
Thx,
Norman
2010/8/21 Norman Maurer<nor...@apache.org>:
Well I need to revert it ;) I will do so then..
Bye,
Norman
2010/8/21 Norman Maurer<nor...@apache.org>:
Hi Tim,
comments inside..
2010/8/21 Tim-Christian Mundt<d...@tim-erwin.de>:
Norman,
you are right in that it was kinda double, so there should be some
cleanup. My first attempt would have been to remove the subscription
stuff from the MailboxManager (your option #1). The reason is
that we
always have a manager and its respective mapper. Now we have the
MailboxManager with two Mappers. I think we should also merge
them which
would also simplify the package structure because we wouldn't need
the .mail and .user packages anymore.
Thats true I just thought it would be more easy to have not to many
interfaces to implement. Anyway I would also be happy to move the
subscripe stuff to any extra interface. I just don't like to have it
duplicated so feel free to revert...
One more thing concerning naming and stuff: Now the
DelegatingMailboxManager is not really delegating anymore. Is
there any
good reason we should keep it separate from StoreMailboxManager?
If not
I'd rather have a little bigger class but fewer hierarchy levels.
I need to review..
Any thoughts?
Tim
Am Samstag, den 21.08.2010, 10:23 +0200 schrieb Norman Maurer:
I just committed the changes.. If anyone thinks its a bad idea
we can
revert it anyway..
https://issues.apache.org/jira/browse/IMAP-205
Bye,
Norman
2010/8/21 Norman Maurer<nor...@apache.org>:
Hi there,
after looking again at the IMAP api I'm in favor of removing the
org.apache.james.imap.store.Subscriper interface and merge the
implementations with the MailboxManager implementations. Thats
because
the Subsciper interface has 3 methods, all of the methods are
already
in MailboxManager. So the MailboxManager just wraps the Subscriper
implementation and delegate the call to it.
So there are two solutions to this:
1) Remove the methods from MailboxManager and move the Subscriper
interface to the mailbox api
2) Remove the Subscriper interface from store api and merge the
implementations
As I stated before I would prefer 2).
WDYT ?
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
