Hi Eric, please see inline.
Best, gazda On Thu, Jun 28, 2012 at 11:43 AM, Eric Charles <[email protected]> wrote: > Looking at the diffs in the order as there are shown on [1]: [1] is now outdated, one can use https://github.com/gazdahimself/current/compare/master...MAILBOX-175 to see the relevant diffs. > API > > 1.- profile noTest on mailbox-integration-tester: ok > > 2.- LocalAndVirtualMailboxLocatorChain: what's the goal? MailDir is a file system based storage. There is the MaildirLocator interface for mapping of MailboxNames to file system directories and back. There are two basic MaildirLocator implementations: LocalSystemMaildirLocator (maps to /home/<user>/MailDir) and VirtualMailboxLocator (maps to <virtualRoot>/<domain>/<user>). The third one, LocalAndVirtualMailboxLocatorChain, cobines the two. > 3.- MailboxPath is now MailboxName: Path sounded more like > folder/subfolder/subfolder. Yes, I agree, that is the case for common English. But there is no single occurence of 'path' in RFC3501. It speaks only about (hierarchical) names. On the other hand, MailboxPath/MailboxName is our internal term which does not map 1:1 to the IMAP hierachical name. We can name it however we want. I am not against going back to MailboxPath. > 4.- MailboxNameResolver on MailboxManager You mean that the methods from MailboxNameResolver should better move to MailboxManager? - Well, MailboxManager is defines storage operations, but MailboxNameResolver interprets names. That is something different. Two distinct MailboxNameResolvers are conceivable for a single MailboxManager; see (5) in my previous post ( /users/<username> vs. /users/<username>/INBOX ). > 5.- MailboxSession has no more PersonalSpace nor UserSpace but a > MailboxOwner. The capability to list namespace prefixes has moved from MailboxSession to MailboxNameResolver, which is now a member of MailboxSession. Listing namespace prefixes belongs to the mailbox hierarchy definition entailed in MailboxNameResolver. MailboxOwner is needed to distinguish groups from persons and 'normal' (domain-less) users from virtual users. > 6. SubscriptionManager now works with MailboxName and no more with String > for mailboxname; OK > > 7. MailboxACL and MailboxACLCodec: already there before I think Yes. > 8. mmh, MailboxPath is still there. Yes, it is still there because there are still references to it from mailets project which I was not able to fix. Otherwise there are only refs in comments which can generally be replaced by MailboxName. > 9. MailboxNameSerializer, MailboxNameBuilder, MailboxNameCodec, > MailboxNamespaceType, MailboxNameEscaper MailboxNameSerializer belongs to my first attempts. It could be made parent of MailboxNameCodec or replaced altogether. As for MailboxNameCodec cf. (6) of my previous post. MailboxNameBuilder - allows for saving some memory and string-copying when creating a new MailboxName. MailboxNameEscaper - ancillary interface for MailboxNameCodec. MailboxNameCodec implementations mostly differ only in the MailboxNameEscaper they use. > 10. LikeSearchPatternEscaper: why deal with JCR, SQL in the API? It is not API, but common to many API consumers. Can you see a better place for it? > 11. More and more unit tests... :) Finite verb? > JCR, JPA and MEMORY Modules > > 12. I guess this is the impact of the API changes. > > HBASE > > 13. Didn't see any change in the diff > > SPRING The change in spring-mailbox-jpa.xml is only white space. Reverting. > 14. I guess this is the impact of the API changes. > > STORE > > 14. I guess this is the impact of the API changes. > > PROTOCOLS IMAP > > 15. Sounds logic imap is the only impacted module > > So very very impressive changes. May I summary them as more typing for > domains that ease the reading and implementation of ACL and the overall > mailbox? Well, yes, definitely more typing - that is con. Pros are: - Handling mailbox names more reliably - Mailbox names are interpreted on one central place. - Namespace prefixes other than personal are now possible, esp. group folders are possible > To be honest, I didn't see well if and how the ACL are applied... :) New in my proposal is only that the ACLs can now be stored in JPA, JCR and HBase in addition to MailDir. They are still not enforced though. https://issues.apache.org/jira/browse/IMAP-358 is still open for that matter. > [1] > https://github.com/gazdahimself/current/commit/ae75a54400bc7aa93763657a48596d09ec357f98, [1] is now outdated, one can use https://github.com/gazdahimself/current/compare/master...MAILBOX-175 to see the relevant diffs. > > On 06/27/2012 06:55 PM, Jochen Gazda wrote: >> >> Gentlemen, >> >> I have finally managed it to publish my changeset on GitHub: >> https://github.com/gazdahimself/current/tree/MAILBOX-175 >> The state of my brach MAILBOX-175 is in sync with the currently latest >> svn revision 1354581. My brach MAILBOX-175 can also be diffed against >> svn revision 1354581 directly on GitHub. >> >> Sorry for the delay, I am new to git and I have a new job. >> >> Please comment. >> >> Best, >> >> gazda >> >> On Wed, Jun 13, 2012 at 1:51 PM, Ioan Eugen Stan<[email protected]> >> wrote: >>> >>> HI Gazda, >>> >>> Git is great. >>> >>> Cheers, >>> >>> 2012/6/13 Eric Charles<[email protected]>: >>>> >>>> Hi Gazda, >>>> >>>> I'm fine with the push to your personal github. It offers nice ui to >>>> show >>>> diffs. >>>> >>>> Thx, Eric >>>> >>>> >>>> On 06/13/2012 10:32 AM, Jochen Gazda wrote: >>>>> >>>>> >>>>> Gentlemen, >>>>> >>>>> I could invest about 6 weeks of my time into solving >>>>> https://issues.apache.org/jira/browse/MAILBOX-175 and >>>>> https://issues.apache.org/jira/browse/MAILBOX-167. >>>>> The result is quite a huge and deep changeset. There is a de facto >>>>> replacement for MailboxPath - so you can imagine, how many classes >>>>> were changed. >>>>> >>>>> Before going too much into details I wanted to agree on a way how my >>>>> changeset could find its way into SVN. >>>>> >>>>> The changes should be discussed before they are committed to trunk. >>>>> But I am not sure what is the best way to share my changes before they >>>>> are committed to trunk. >>>>> Would cloning from http://git.apache.org/ and pushing changes to my >>>>> personal GitHub repo be a viable solution? >>>>> I am also ready to send my zipped workspace (~30MB) to anybody who >>>>> wants to have a quick look. >>>>> >>>>> Best, >>>>> >>>>> gazda >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> -- >>>> eric | http://about.echarles.net | @echarles >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> >>> -- >>> Ioan Eugen Stan / http://axemblr.com / Tools for Clouds >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > -- > eric | http://about.echarles.net | @echarles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
