james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Gazda <gazdahims...@gmail.com>
Subject Make the namespace handling consistent and predictable
Date Tue, 21 Feb 2012 19:31:03 GMT

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

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;


        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.



To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message