[ http://issues.apache.org/jira/browse/JCR-184?page=comments#action_12330028 ]
Brian Moseley commented on JCR-184: ----------------------------------- angela, thanks for putting some time into this. my particular situation has some constraints and assumptions that lessen the importance of some of your considerations and findings relative to my needs. specifically, i'm not concerned with usage of the repository in any context other than my application's webdav and webui interfaces. this means: * i am willing to live with garbled item names * if we can provide a name translation utility that can be used outside the webdav layer, then other interfaces on top of the repository (eg my webui) can take advantage of it as well from an outsider's perspective, the limitation seems artificial and perhaps indicative of a design flaw somewhere within jcr-server or in the jcr api itself. it's difficult for me to explain to end users, potential customers, and my management why i can't support certain very useful characters in webdav resource names (no "Brian's Calendar" caldav collection allowed). it certainly does not help give them confidence that my architectural choice of jcr was well-founded. our competitors, all of whom use relational databases, don't have this limitation. that said, i can live without support for the reserved characters for a while. my product is stlll early in its development. eventually though i will have to find a solution. it may well be the case that this is an issue that needs to be discussed for jcr 2.0. it might be possible to relax the restrictions on item names. > Simple Webdav: jcr-encoding for resource names contain invalid characters. > -------------------------------------------------------------------------- > > Key: JCR-184 > URL: http://issues.apache.org/jira/browse/JCR-184 > Project: Jackrabbit > Type: Improvement > Reporter: Brian Moseley > Assignee: angela > Priority: Minor > > jcr-server is a bit problematic in the way it treats the display name of a > webdav resource. specifically it forces the display name to be the same as > the name of the resource itself, rather than an arbitrary textual description > of the resource. this is an acceptable default value for a resource's display > name, but a webdav client should be able to change the display name at any > point after creation of the resource. > rfc 2518 says: > 13.2 displayname Property > Name: displayname > Namespace: DAV: > Purpose: Provides a name for the resource that is suitable for > presentation to a user. > Description: The displayname property should be defined on all DAV > compliant resources. If present, the property contains a description > of the resource that is suitable for presentation to a user. > <!ELEMENT displayname (#PCDATA) > > i realize that the goal of the simple webdav server is to support > nt:collection and nt:file, which don't allow extra properties. that's fine; i > have defined my own dav:collection and dav:resource node types on which i can > add a dav:displayname property. i can then override > DavResourceImpl.getDisplayName() to return the value of that property. > the problem is that DavResourceImpl.getDisplayName() as already implemented > has a couple of other purposes - calculating the resource name for a node > that is about to be created and returning the resource name from an existing > node. > furthermore, both resource and display names could potentially contain > characters that are illegal in jcr names. we've talked in the past about > encoding these strings in order to use them as jcr names. this encoding would > be necessary for the resource name (which is used as the node's name) but not > for the display name (which would be persisted as a property value). > i propose the following DavResourceImpl methods: > getResourceName() - returns the (unencoded) name of the resource, which is > either the name of the resource's node (if the resource exists) or the final > segment of the resource's uri path > getDisplayName() - returns the value of the resource's DAV:displayname > property (if both the resource and property exist) or the string returned > from getResourceName > DavResourceImpl could simply always `return getResourceName()' as its > implementation of getDisplayName(). subclasses would be free to override it > to retrieve the display name from a jcr property. > DavResourceImpl would also take care of encoding the resource name before > creating the new node and decoding the resource name before returning it from > getResourceName(). > thoughts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
