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,
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]
