james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Charles <e...@apache.org>
Subject Re: Improved MailboxPath and how to handle the resulting change set
Date Thu, 28 Jun 2012 10:53:56 GMT
Hi Gazda,

Thx for bringing more details on the changes. I will further read and 
comment (your mail crossed my previous one).

I would like to invite all existing users/developers already working 
with the mailbox-api to express their thinkings.

AFAIK, there are a few developers already using the mailbox-api, and 
this will largely impact their implementation.

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).

I will off the next 2 weeks. I'm not mandatory, but we should wait 
enough time to gather potential feedbacks from everyone (better to 
launch a new thread for this to bring needed attention).

For your remaining points:

(i) we can always let evolve after

(ii) we have a mailbox-copier for upgrades 
(http://james.apache.org/server/3/upgrade-database.html). you can copy 
any mailbox to maildir, upgrade the server, and copy back maildir to the 
new mailbox. Not elegant, but it has proven to work...

(iii) how is mailet project impacted?

Thx again,


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

View raw message