I have filled this in Jira under
https://issues.apache.org/jira/browse/MAILBOX-167
On Tue, Feb 21, 2012 at 8:31 PM, Jochen Gazda <gazdahims...@gmail.com> wrote:
> Gentlemen,
>
> On the way to usable group folders and ACL, I found that namespaces
> are not handled consistently.
>
> (1) in StoreMessageManager.isGroupFolder(MailboxSession), if the
> present folder is the current user's INBOX, mailbox.getNamespace() and
> session.getPersonalSpace() should return the same value, which they do
> not.
>
> I could achieve the desired behavior when I changed this part of
> SimpleMailboxSession constructor from
>
> if (otherUsersSpace == null && (sharedSpaces == null ||
> sharedSpaces.isEmpty())) {
> this.personalSpace = "";
> } else {
> this.personalSpace = MailboxConstants.USER_NAMESPACE;
> }
>
> to
>
> this.personalSpace = MailboxConstants.USER_NAMESPACE;
>
> Can this cause any unwanted consequences?
>
> (2) in AbstractMailboxProcessor.buildFullPath(ImapSession, String),
> MailboxConstants.USER_NAMESPACE is used on two places where IMO
> mailboxSession.getPersonalSpace() would be a better choice just for
> the case that -- for whatever reason -- the session gets configured
> differently. Is it a good idea?
>
> (3) I find the rewriting of "" and null namespace values to
> MailboxConstants.USER_NAMESPACE in MailboxPath(String, String, String)
> constructor problematic. Callers should be fully responsible for the
> namespace value.
> "" should be allowed as a legal namespace prefix, e.g. for a shared namespace.
> As for null, is there any good reason for the rewriting?
> I see that changing the rewriting of "" and/or null namespace in
> MailboxPath would enforce an extensive refactoring.
>
> (4) MailboxPath has three fields: namespace, user and name. We should
> make them final and their setters should be removed to avoid
> unauthorised or unexpected changes. As far as I can see there are only
> a few easily refactorable locations where the setters are invoked.
>
> Best,
>
> gazda
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
