Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
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 Maurernor...@apache.org: Well I need to revert it ;) I will do so then.. Bye, Norman 2010/8/21 Norman Maurernor...@apache.org: Hi Tim, comments inside.. 2010/8/21 Tim-Christian Mundtd...@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 Maurernor...@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:
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
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 Maurernor...@apache.org: Well I need to revert it ;) I will do so then.. Bye, Norman 2010/8/21 Norman Maurernor...@apache.org: Hi Tim, comments inside.. 2010/8/21 Tim-Christian Mundtd...@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 Maurernor...@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,
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
Hi Tim, 2010/8/21 Tim-Christian Mundt d...@tim-erwin.de: 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_: ok :) 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. 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 .. 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 Bye, Norman - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
Hi Eric.. 2010/8/22 Eric Charles e...@apache.org: Hi, So Tim, you was also ok with optin 2 and finally Norman reverted to option 1 ? (not sure to be in line :) ?) Seems so.. 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) yeah I will update the springs-beans.xml once we know howto process. 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. We need the Subscription stuff in some Processors, thats why we need it here. 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 Maurernor...@apache.org: Well I need to revert it ;) I will do so then.. Bye, Norman 2010/8/21 Norman Maurernor...@apache.org: Hi Tim, comments inside.. 2010/8/21 Tim-Christian Mundtd...@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 Maurernor...@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
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
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
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
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
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
one more inline :) On 22/08/2010 13:58, Norman Maurer wrote: 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. Yeah, these are soft links. A Subscription store could be different from the Mailbox store (so we have links via String). Example: - Users are stored in LDAP tks to james-server. - Mailbox in DB via JPA. - Subscription soft link LDAP to DB and these soft links are store anywhere defined by the admin (in spring-beans.xml). (snippped...) Just as a side-note... For example the subscription stuff is not really necessary for using MailboxManager in non-imap enviroments (for example pop3). True enough. I re-read the pop3 case, and I see one more argument to leave the SubscriptionManager independent of the MailboxManager. So http://svn.apache.org/viewvc?rev=987821view=rev Move the Subscriper to the mailbox api and rename it SubscriptionManager... makes all its sense. There's still the open question on start/stopProcessing and listener (to be duplicated in Mailbox/SubscriptionManager or externalized ?). To take a decision , we should also consider that operations need to be atomic, so encapsulate the Mailbox/SubscriptionManager processing. So externalize/encapsulate makes some sense, as you communicated me ? - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
Comments inline.. 2010/8/22 Eric Charles e...@apache.org: one more inline :) On 22/08/2010 13:58, Norman Maurer wrote: 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. Yeah, these are soft links. A Subscription store could be different from the Mailbox store (so we have links via String). Example: - Users are stored in LDAP tks to james-server. - Mailbox in DB via JPA. - Subscription soft link LDAP to DB and these soft links are store anywhere defined by the admin (in spring-beans.xml). (snippped...) Just as a side-note... For example the subscription stuff is not really necessary for using MailboxManager in non-imap enviroments (for example pop3). True enough. I re-read the pop3 case, and I see one more argument to leave the SubscriptionManager independent of the MailboxManager. So http://svn.apache.org/viewvc?rev=987821view=rev Move the Subscriper to the mailbox api and rename it SubscriptionManager... makes all its sense. There's still the open question on start/stopProcessing and listener (to be duplicated in Mailbox/SubscriptionManager or externalized ?). To take a decision , we should also consider that operations need to be atomic, so encapsulate the Mailbox/SubscriptionManager processing. So externalize/encapsulate makes some sense, as you communicated me ? I don't know yet.. whats you preference ? Bye, Norman - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
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
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
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. 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. 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
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
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
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
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
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
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
Re: [IMAP] Remove org.apache.james.imap.store.Subscriper
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
