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 09:21:09 GMT
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


Mime
View raw message