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:00:58 GMT
Hi Eric,

please see inline.

Best,

gazda

On Thu, Jun 28, 2012 at 11:43 AM, Eric Charles <eric@apache.org> wrote:
> Looking at the diffs in the order as there are shown on [1]:

[1] is now outdated, one can use
https://github.com/gazdahimself/current/compare/master...MAILBOX-175
to see the relevant diffs.

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

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

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

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

MailboxOwner is needed to distinguish groups from persons and 'normal'
(domain-less) users from virtual users.

> 6. SubscriptionManager now works with MailboxName and no more with String
> for mailboxname; OK
>
> 7. MailboxACL and MailboxACLCodec: already there before I think

Yes.

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

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

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

> 11. More and more unit tests... :)

Finite verb?

> JCR, JPA and MEMORY Modules
>
> 12. I guess this is the impact of the API changes.
>
> HBASE
>
> 13. Didn't see any change in the diff
>
> SPRING

The change in spring-mailbox-jpa.xml is only white space. Reverting.

> 14. I guess this is the impact of the API changes.
>
> STORE
>
> 14. I guess this is the impact of the API changes.
>
> PROTOCOLS IMAP
>
> 15. Sounds logic imap is the only impacted module
>
> So very very impressive changes. May I summary them as more typing for
> domains that ease the reading and implementation of ACL and the overall
> mailbox?

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

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

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


Mime
View raw message