You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Jochen Gazda <ga...@gmail.com> on 2012/02/21 20:31:03 UTC
Make the namespace handling consistent and predictable
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
Re: Make the namespace handling consistent and predictable
Posted by Jochen Gazda <ga...@gmail.com>.
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 <ga...@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