On 2013-10-01 16:17, Jukka Zitting wrote:
Hi,
On Tue, Oct 1, 2013 at 10:06 AM, Julian Reschke <[email protected]> wrote:
What are our expections with respect to certain normalizations of node names
a repository *might* do, such as:
From the implementation perspective: I think such concerns should be
taken care of on a level above the repository. At best I'd see the
repository enforcing a particular naming policy by refusing to create
content with un-normalized names.
It seems that's an approach that isn't going to work with existing
clients. See
<http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10552.html> for
a discussion of a similar issue in NFS land.
What might be more promising is to store the names as supplied by the
client (which keeps existing code happy), but to normalize on lookup.
However, this really would need to be done at the repository level
(maybe as an option). For classic Jackrabbit this might mean that we
have to fiddle around with the name lookup in ChildNodeEntries.
From the client perspective: I guess a client should be prepared for a
repository that actively does normalize names, as I don't think the
spec rules something like that out and as the spec was written in a
way that would allow it to be implemented on top of existing backends
that already may do such normalization. In practice that would
probably mean that a Node returned from getNode() or addNode() might
not have the exact same name as the one given as the argument.
Normalize-to-NFC-on-create will break OSX WebDAV I hear (I'm pretty sure
the opposite would be true for Windows).
Best regards, Julian
