james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioan Eugen Stan <stan.ieu...@gmail.com>
Subject Re: Improved MailboxPath and how to handle the resulting change set
Date Thu, 28 Jun 2012 16:19:12 GMT
Just finished reading the emails. I don't know of any mailbox-hbase
users and a MapReduce job for converting one schema to another is, in
my opinion, not a big deal. My point is that the the schema
incompatibility with regard to HBase is not an issue for now. The only
thing is that we should release fast after this so it won't be a
problem for future users.

Will look at the code soon with more comments, but looks very good.
Any issues should be solvable.

Great work Gazda,

Cheers,

2012/6/28 Eric Charles <eric@apache.org>:
> On 06/28/2012 04:00 PM, Jochen Gazda wrote:
>>>
>>> 1.- profile noTest on mailbox-integration-tester: ok
>>>
>>> 2.- LocalAndVirtualMailboxLocatorChain: what's the goal?
>>
>>
>> MailDir is a file system based storage. There is the MaildirLocator
>> interface for mapping of MailboxNames to file system directories and
>> back. There are two basic MaildirLocator implementations:
>> LocalSystemMaildirLocator (maps to /home/<user>/MailDir) and
>> VirtualMailboxLocator (maps to<virtualRoot>/<domain>/<user>). The
>> third one, LocalAndVirtualMailboxLocatorChain, cobines the two.
>>
>
> Ok, got it.
> (naming is just not consistent across LocalSystemMaildirLocator /
> VirtualMailboxLocator / LocalAndVirtualMailboxLocatorChain (you have Maildir
> in the first, not in the others).
>
>
>
>>> 3.- MailboxPath is now MailboxName: Path sounded more like
>>> folder/subfolder/subfolder.
>>
>>
>> Yes, I agree, that is the case for common English. But there is no
>> single occurence of 'path' in RFC3501. It speaks only about
>> (hierarchical) names. On the other hand, MailboxPath/MailboxName is
>> our internal term which does not map 1:1 to the IMAP hierachical name.
>> We can name it however we want. I am not against going back to
>> MailboxPath.
>>
>
> The key is 'hierarchical'. I find MailboxPath correctly reflect this point.
> With MailboxName, you loose that, and MailboxHierarchicalName is just too
> long.
>
> At first sight, I would prefer to revert to MailboxPath.
>
>
>>> 4.- MailboxNameResolver on MailboxManager
>>
>>
>> You mean that the methods from MailboxNameResolver should better move
>> to MailboxManager? - Well, MailboxManager is defines storage
>> operations, but MailboxNameResolver interprets names. That is
>> something different. Two distinct MailboxNameResolvers are conceivable
>> for a single MailboxManager; see (5) in my previous post (
>> /users/<username>  vs. /users/<username>/INBOX ).
>>
>
> I was just pointing an additional method MailboxNameResolver
> getMailboxNameResolver(); on the MailboxManager interface.
>
> So good as is.
>
>
>>> 5.- MailboxSession has no more PersonalSpace nor UserSpace but a
>>> MailboxOwner.
>>
>>
>> The capability to list namespace prefixes has moved from
>> MailboxSession to MailboxNameResolver, which is now a member of
>> MailboxSession. Listing namespace prefixes belongs to the mailbox
>> hierarchy definition entailed in MailboxNameResolver.
>>
>
> OK
>
>
>> MailboxOwner is needed to distinguish groups from persons and 'normal'
>> (domain-less) users from virtual users.
>>
>
> So you assume a mailbox has always an owner.
> Sounds logical, but is it sustained by the RFC?
>
>
>>> 8. mmh, MailboxPath is still there.
>>
>>
>> Yes, it is still there because there are still references to it from
>> mailets project which I was not able to fix.
>> Otherwise there are only refs in comments which can generally be
>> replaced by MailboxName.
>>
>
> Would it be solved if we revert from MailboxName to MailboxPath?
>
>
>>> 9. MailboxNameSerializer, MailboxNameBuilder, MailboxNameCodec,
>>> MailboxNamespaceType, MailboxNameEscaper
>>
>>
>> MailboxNameSerializer belongs to my first attempts. It could be made
>> parent of MailboxNameCodec or replaced altogether. As for
>> MailboxNameCodec cf. (6) of my previous post.
>> MailboxNameBuilder - allows for saving some memory and string-copying
>> when creating a new MailboxName.
>>
>> MailboxNameEscaper - ancillary interface for MailboxNameCodec.
>> MailboxNameCodec implementations mostly differ only in the
>> MailboxNameEscaper they use.
>>
>
> I need to read back all this.
> Is the goal of all these classes to better support mailbox name charsets and
> to build the hierachical mailbox name structure in a efficient way?
>
>
>>> 10. LikeSearchPatternEscaper: why deal with JCR, SQL in the API?
>>
>>
>> It is not API, but common to many API consumers. Can you see a better
>> place for it?
>>
>
> I would prefer not to have them in the API, but we can leave it as such for
> now.
>
>
>>> 11. More and more unit tests... :)
>>
>>
>> Finite verb?
>>
>
> ... is good :)
>
>
>>
>> Well, yes, definitely more typing - that is con.
>> Pros are:
>>  - Handling mailbox names more reliably
>>  - Mailbox names are interpreted on one central place.
>>  - Namespace prefixes other than personal are now possible, esp. group
>> folders are possible
>>
>
> As con, you will end with a few more object to instantiate, mainly on
> mailbox selection, but IMHO I this won't be an issue at all
>
>
>>> To be honest, I didn't see well if and how the ACL are applied... :)
>>
>>
>> New in my proposal is only that the ACLs can now be stored in JPA, JCR
>> and HBase in addition to MailDir. They are still not enforced though.
>> https://issues.apache.org/jira/browse/IMAP-358 is still open for that
>> matter.
>>
>
> OK, with these changes, you are now in a better place to implement the ACL.
>
>
>>> [1]
>>>
>>> https://github.com/gazdahimself/current/commit/ae75a54400bc7aa93763657a48596d09ec357f98,
>>
>>
>> [1] is now outdated, one can use
>> https://github.com/gazdahimself/current/compare/master...MAILBOX-175
>> to see the relevant diffs.
>>
>>
>>>
>>> On 06/27/2012 06:55 PM, Jochen Gazda 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
>>
>
> --
> 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 / CTO / http://axemblr.com

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