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: Make the namespace handling consistent and predictable
Date Tue, 21 Feb 2012 21:14:00 GMT
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 <gazdahimself@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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message