james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Gazda <gazdahims...@gmail.com>
Subject Re: Improved MailboxPath and how to handle the resulting change set
Date Thu, 28 Jun 2012 14:10:32 GMT
Hi Eric,

see inline,

Best,

gazda

On Thu, Jun 28, 2012 at 12:53 PM, Eric Charles <eric@apache.org> 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<gazdahimself@gmail.com>
>>  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<stan.ieugen@gmail.com>
>>>  wrote:
>>>>
>>>> HI Gazda,
>>>>
>>>> Git is great.
>>>>
>>>> Cheers,
>>>>
>>>> 2012/6/13 Eric Charles<eric@apache.org>:
>>>>>
>>>>> 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: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>> --
>>>>> eric | http://about.echarles.net | @echarles
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ioan Eugen Stan / http://axemblr.com / Tools for Clouds
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
> --
> eric | http://about.echarles.net | @echarles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message