[
https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260668#comment-13260668 ]
Ioan Eugen Stan commented on MAILBOX-175:
-----------------------------------------
Wow, you definitely took some time to analyze this. I also found Mailnbox and MailboxPath handling a bit fishy but didn't do anything. I ill take some time to look into this and come back with feed-back and impressions. Please add the rfc's and pages used for documentation as reference so we will all follow.
> 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.jspaFor more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail:
server-dev-unsubscribe@...
For additional commands, e-mail:
server-dev-help@...