Hi Eric, see inline,
Best, gazda On Thu, Jun 28, 2012 at 12:53 PM, Eric Charles <[email protected]> wrote: > I would like to invite all existing users/developers already working with > the mailbox-api to express their thinkings. Yes, please comment! > AFAIK, there are a few developers already using the mailbox-api, and this > will largely impact their implementation. Yes definitely, please comment! > They may have ideas/proposals to take into account at this stage. > > They may also be worried about your (ii) point: JCR/JPA/HBase schema change. > I hope maildir persistence format is not changed, or at least can be > transparently upgraded (it shouldn't as it is a defacto standard). Yes, I confirm, that MailDir format stays backward compatible with my proposal. > I will off the next 2 weeks. Have a nice holiday! > [...] > > (iii) how is mailet project impacted? There are still references to MailboxPath in mailets project. Unfortunatelly I was not able to grasp the purpose of those refs and I was not able to fix them. > Thx again, > > Eric > > > On 06/28/2012 11:21 AM, Jochen Gazda wrote: >> >> Gentlemen, >> >> I have fixed some minor issues in my proposal so please consider my >> update from 2012-06-28 10:38 CEST (+02:00) >> https://github.com/gazdahimself/current/commits/MAILBOX-175 >> >> Let me introduce my MailboxPath replacement briefly. >> >> (1) Firstly, here is the list of issues I consider solved by my proposal: >> https://issues.apache.org/jira/browse/MAILBOX-175 >> https://issues.apache.org/jira/browse/MAILBOX-167 >> https://issues.apache.org/jira/browse/MAILBOX-176 >> >> (2) Please read esp. the following post to understand the motivation >> for this proposal: >> >> https://issues.apache.org/jira/browse/MAILBOX-175?focusedCommentId=13260641&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13260641 >> >> (3) MailboxPath is replaced by >> org.apache.james.mailbox.name.MailboxName/DefaultMailboxName. It can >> be characterized as follows: >> - umodifiable >> - it stores only the path segments of a hierarchical name plus >> hasRoot attribute >> - offers no way to directly interpret the individual path segments as >> referring to IMAP namespace, user name, etc. When this kind of >> interpretation is needed it can be done using MailboxNameResolver - >> see (5) >> - knows nothing about delimiter because delimiter matters only to its >> serialization and deserialization, which is done using >> MailboxNameCodec - see (6) >> >> (4) Except for MailboxName which is to be considered context >> independent, there is UnresolvedMailboxName. UnresolvedMailboxName is >> the direct representation of mailbox names coming in and out over the >> IMAP wire. The meaning of UnresolvedMailboxName may depend on >> information available in the context of the given IMAP session, such >> as user name of the current user. Both directions of >> UnresolvedMailboxName<-> MailboxName transformation can be done using >> MailboxNameResolver. >> >> (5) MailboxNameResolver/DefaultMailboxNameResolver - except for >> UnresolvedMailboxName<-> MailboxName transformations, it defines the >> layout of the mailbox name hierarchy. >> It is able to: >> - tell which part of a given MailboxName is to be interpreted as >> namespace, user name, ... >> - tell if the given MailboxName is INBOX of a given user >> - construct INBOX MailboxName for a given user, etc. >> >> It is possible to define alternative hierarchy layouts with new >> MailboxNameResolver implementations. >> For instance there are two common interpretations, where INBOX is >> placed in current IMAP servers: >> (a) /users/<username> >> (b) /users/<username>/INBOX or /users/<username>/Inbox >> DefaultMailboxNameResolver adheres to (a) >> >> (6) MailboxNameCodec - my vision was to decouple the delimiter used on >> the IMAP wire from the delimiter used in mailbox stores, thus avoiding >> some problems, e.g. related to the lack of delimiter escaping rules in >> the IMAP RFCs. I thought, with this decoupling one can choose a much >> more robust MailboxNameCodec (with its own consistent >> delimiter-escaping rules) for the store than one can for IMAP >> protocol. If there come an RFC defining IMAP delimiter escaping one >> day one would only need to switch the MailboxNameCodec for IMAP. >> With my proposal, it is indeed possible, but not for all mailbox >> stores. MailDir for instace prescribes the '.' delimiter which IMO the >> worst one from the commonly used ones. >> >> Although my proposal solves quite a long list of issues there remain >> some points to discuss or improve: >> >> (i) DefaultMailboxNameResolver and its usage is by no means elegant >> >> (ii) I have changed the schema of JCR, JPA and HBase backend thus >> making them incompatible with already stored data and I do not provide >> any transformations from old schemata to the new ones. >> >> (iii) There are some compilation errors in mailets project which I was >> not able to resolve myself. I would ask for assistance when there is a >> broader consensus about my proposal. >> >> Please comment. >> >> Best, >> >> gazda >> >> On Wed, Jun 27, 2012 at 6:55 PM, Jochen Gazda<[email protected]> >> 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]
