[ https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260869#comment-13260869 ]
Jochen Gazda commented on MAILBOX-175: -------------------------------------- Ioan, I see only http://www.apps.ietf.org/rfc/rfc2342.html and http://tools.ietf.org/html/rfc3501 esp. http://tools.ietf.org/html/rfc3501#section-5.1.1 as relevant for this discussion. > 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