jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: [Jackrabbit Wiki] Update of "Jsop" by stefan
Date Wed, 14 Dec 2011 14:04:37 GMT
Hi,

Am 14.12.2011 um 14:10 schrieb Thomas Mueller:

> Hi,
> 
> In my view, we should try to stay compatible with DavEx JSOP, except for
> those cases where DavEx JSOP is problematic:
> 
> - I think it didn't require paths to be double quoted?
> 
> - Move operations were defined as > "/from": "/to" [#before|#after], which
> is problematic from a parser point of view, because optional token at the
> end of "logical line" are ambiguous (the token might belong to the next
> logical line).
> 
>> Sling JSOP
> 
> I believe the 'diff' part within Sling isn't implemented yet, right? I
> guess The Sling JSOP should be compatible with what we do for Jackrabbit 3
> as much as possible, but the use cases might be slightly different.

Absolutely. I tend to think any Sling JSOP implementation would best reuse an existing parser
instead of writing its own stuff.

> 
>> IETF JSON Diff
> 
> I think our work will influence IETF JSON Diff. The "test" and "move"
> operation were already added, I guess the "copy" operations will be added
> as well, because it simply makes sense to have such an operation.
> 
> I think the standards are still ambiguous in a few areas. One is the exact
> specification of a "path" and "path element". I saw that
> draft-pbryan-json-patch-02.txt assumes a number at the end of a path is an
> array index: "Moving an Array Element" - "/foo/1" refers to the second
> element in the array "/foo". That could mean number are not allowed as
> path elements (there could be no node called "/foo/1"). Another problem we
> ran into is adding a 'options mechanism' in the getNodes call. One idea is
> to append ";hash" to the path if the server should include the content
> hash for each node. That means getNode("/foo;hash") would return the node
> "/foo", together with the ":hash" property (in our implementation).

Is this IETF draft or your extension ? Anyways, it feels extremely strange.

Regards
Felix
Mime
View raw message