On 2013-10-08 17:19, Jukka Zitting wrote:
Hi,
On Tue, Oct 8, 2013 at 8:58 AM, Julian Reschke <[email protected]> wrote:
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.
This is probably fine for a client that treats the repository like a
file system, but potentially highly confusing for ones that assume
database-like semantics. We for example have a number of clients that
store more or less arbitrary key-value mappings in the repository.
Such clients would get subtly broken if it was possible for two
distinct keys to map to the same value.
And these arbitrary keys really require that two different normalization
forms remain different?
Thus I'd be fine with something like this being implemented for
example in the webdav layer, but quite reserved about changing
jackrabbit-core. What's the specific use case behind this?
The use case are real-world users that mix platforms (Windows, Mac) and
browsers (Webkit vs the rest) and end up with two nodes where there
should be only one.
And no, it would need to be done consistently (file upload through
browser, WebDAV access, other HTTP based APIs, etc), and thus would be
very hard to do all over the place.
I wonder whether we could make normalization (or lack of it) depend on a
mixin type?
Best regards, Julian
