Re: node naming

Hi, On Wed, Oct 9, 2013 at 10:37 AM, Julian Reschke wrote: > On 2013-10-09 15:43, Jukka Zitting wrote: >> In some cases yes. However, there shouldn't be any noticeable overhead >> in the common case where both the client and the server are using >> normalized names. And anyone who doesn't do that

Re: node naming

On 2013-10-09 15:43, Jukka Zitting wrote: Hi, On Wed, Oct 9, 2013 at 3:41 AM, Julian Reschke wrote: That sounds like you propose to do the normalization-on-lookup one layer above the JCR API. Won't that be extremely expensive? In some cases yes. However, there shouldn't be any noticeable ove

Re: node naming

Hi, On Wed, Oct 9, 2013 at 3:41 AM, Julian Reschke wrote: > That sounds like you propose to do the normalization-on-lookup one layer > above the JCR API. Won't that be extremely expensive? In some cases yes. However, there shouldn't be any noticeable overhead in the common case where both the cl

Re: node naming

On 2013-10-08 22:13, Jukka Zitting wrote: Hi, On Tue, Oct 8, 2013 at 11:45 AM, Julian Reschke wrote: And these arbitrary keys really require that two different normalization forms remain different? I'm afraid they probably do. While it's unlikely for unnormalized data to be used too frequen

Re: node naming

Hi, On Tue, Oct 8, 2013 at 11:45 AM, Julian Reschke wrote: > And these arbitrary keys really require that two different normalization > forms remain different? I'm afraid they probably do. While it's unlikely for unnormalized data to be used too frequently in practice, someone could still easil

Re: node naming

On 2013-10-08 17:19, Jukka Zitting wrote: Hi, On Tue, Oct 8, 2013 at 8:58 AM, Julian Reschke 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 r

Re: node naming

Hi, On Tue, Oct 8, 2013 at 8:58 AM, Julian Reschke 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 potentia

Re: node naming

On 2013-10-08 14:58, Julian Reschke wrote: ... 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. ... Using normalized keys in ChildNodeEntries' n

Re: node naming

On 2013-10-01 16:17, Jukka Zitting wrote: Hi, On Tue, Oct 1, 2013 at 10:06 AM, Julian Reschke 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 car

Re: node naming

Hi, On Wed, Oct 2, 2013 at 11:13 AM, Julian Reschke wrote: > On 2013-10-02 16:29, Jukka Zitting wrote: >> Only if you're already prepared to deal with such changes. If you're >> not, I think it'll be clearer to fail fast (with a good enough >> explanation in the exception message) than to silentl

Re: node naming

On 2013-10-02 16:32, Jukka Zitting wrote: Hi, On Wed, Oct 2, 2013 at 10:19 AM, Julian Reschke wrote: Like this: https://issues.apache.org/jira/secure/attachment/12606362/JCR-3675.diff +1 looks good. BTW, I'm not a fan of the '+ " Call chain: "' pattern in exception messages. The logging con

Re: node naming

On 2013-10-02 16:29, Jukka Zitting wrote: Hi, On Tue, Oct 1, 2013 at 10:31 AM, Julian Reschke wrote: Well, the call could either fail (in which case the client would have a hard time to figure out how to proceed), or it can pass (and the returned node would "know" its name). I think I'd pref

Re: node naming

Hi, On Wed, Oct 2, 2013 at 10:19 AM, Julian Reschke wrote: > Like this: > https://issues.apache.org/jira/secure/attachment/12606362/JCR-3675.diff +1 looks good. BTW, I'm not a fan of the '+ " Call chain: "' pattern in exception messages. The logging configuration should take care of how (and if

Re: node naming

Hi, On Tue, Oct 1, 2013 at 10:31 AM, Julian Reschke wrote: > Well, the call could either fail (in which case the client would have a hard > time to figure out how to proceed), or it can pass (and the returned node > would "know" its name). > > I think I'd prefer the latter. Only if you're alrea

Re: node naming

On 2013-10-02 12:41, Julian Reschke wrote: On 2013-10-01 16:31, Julian Reschke wrote: Well, the call could either fail (in which case the client would have a hard time to figure out how to proceed), or it can pass (and the returned node would "know" its name). I think I'd prefer the latter. Q

Re: node naming

On 2013-10-01 16:31, Julian Reschke wrote: Well, the call could either fail (in which case the client would have a hard time to figure out how to proceed), or it can pass (and the returned node would "know" its name). I think I'd prefer the latter. Questions: 1) Is this something the spec nee

Re: node naming

On 2013-10-01 16:17, Jukka Zitting wrote: Hi, On Tue, Oct 1, 2013 at 10:06 AM, Julian Reschke 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 car

Re: node naming

Hi, On Tue, Oct 1, 2013 at 10:06 AM, Julian Reschke 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 be

node naming

Hi there, see : What are our expections with respect to certain normalizations of node names a repository *might* do, such as: - removing leading/trailing whitespace - removing certain characters, such as a traling "." - doing case-insensitive l