[
https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256644#comment-13256644
]
Jochen Gazda commented on MAILBOX-175:
--------------------------------------
>> what does the rfc says regarding "" as namespace ?
>I have no exact reference in my head but Cyrus uses "" for shared namespace.
A small addendum of mine:
It is our own business, what we choose as namespace prefixes. Currently we
always send
NAMESPACE (("" ".")) NIL NIL
to IMAP clients; see NamespaceProcessor.buildPersonalNamespaces(MailboxSession,
ImapSession)
That means "" is the prefix for the personal namespace and there are no other
namespaces.
I.e. we effectively do not support namespaces at the moment.
I propose that we abandon sending "" as a namespace prefix to clients from now
on.
NettyImapSession.supportMultipleNamespaces() should return true.
Then IMAP clients should also cease to send "" namespaces to us and we can
internally declare "" namespace prefix as invalid.
> Make the contract of MailboxPath explicit and documented.
> ---------------------------------------------------------
>
> Key: MAILBOX-175
> URL: https://issues.apache.org/jira/browse/MAILBOX-175
> Project: James Mailbox
> Issue Type: Sub-task
> Components: api
> Reporter: Jochen Gazda
> Assignee: Jochen Gazda
>
> Make the contract of org.apache.james.mailbox.model.MailboxPath explicit and
> documented.
> Points to consider:
> (1) Make all attributes immutable - can be done quite easily, no discussion
> expected.
> (2) Null values should be forbidden for at least for name and namespace
> attributes - NullPointerException will be thrown from constructors. A lot of
> client code uses e.g. getName().length(). Clients should be responsible for
> the proper values when creating new instances of MailboxPath.
> (3) Consider adding a delimiter field. Currently delimiter is implicitly
> present in the name value anyway. It would allow:
> (3.1) removing the delimiter parameter from getHierarchyLevels()
> (3.2) adding relativePath(relativeName) method (which is currently done by
> concatenating path segments with bona fide default delimiter in the client
> code).
> (3.3) name attribute could guarrantee that it does not start with delimiter
> (which is sometimes checked in the client code now). For names starting with
> delimiter, either
> (3.3.a) constructors should throw IllegalStateException or
> (3.3.b) the name attribute would be rewritten silently - should perhaps
> be prefered, because of the existing client code.
> (3.4) Currently, there is no delimiter escaping/unescaping (e.g. in parse()
> or getHierarchyLevels()). Should there be any?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
