jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: JSOP vs JSON-Patch, was: [Jackrabbit Wiki] Update of "Jsop" by stefan
Date Wed, 21 Mar 2012 14:33:31 GMT
sorry, i forgot to cc oak-dev. resending...

On Wed, Mar 21, 2012 at 2:07 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2012-03-21 13:47, Stefan Guggisberg wrote:
>>
>> On Tue, Mar 20, 2012 at 6:53 PM, Julian Reschke<julian.reschke@gmx.de>
>>  wrote:
>>>
>>> Hi,
>>>
>>> so Stefan is cleaning up the JSOP Wiki page (thanks!).
>>>
>>> I think it's time to look again at the difference between the JSOP diff
>>> format (as used in MK.commit()), and the IETF JSON Patch format, now
>>> <http://trac.tools.ietf.org/html/draft-ietf-appsawg-json-patch-01>.
>>>
>>> JSOP has lost it's dependency on member ordering, and JSON Patch now has
>>> "test" and "copy", so it seems the only missing gap is the metadata
>>> feature.
>>
>>
>> WRT the set of operations (add, replace, copy et al) i agree that there's
>> a
>> nice 1:1 match.
>
>
> Thanks for confirming.
>
> So should I start work on a spec that defines "JSOP diff" as syntactical
> variant of draft-ietf-appsawg-json-patch-01?

yes, i guess it would make sense.

>
>
>> WRT the metadata feature. it might be useful in certain situations but
>> i am not sure whether we really need it.
>
>
> I assume it's needed for the commit message in MK, but that of course could
> be separated into a separate string argument.

the commit msg is already passed as a separate argument in the commit method.

thomas' proposal referred to an alternative format of getJournal
return value [1].
this has been discussed on the dev list a while ago [2].

IMO it does seem useful but i don't know whether or how we should
specify that as a proposed extension to JSON patch.

[1] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-mk/src/main/java/org/apache/jackrabbit/mk/api/MicroKernel.java
[2] http://www.mail-archive.com/dev@jackrabbit.apache.org/msg26796.html

>
>
>>> If this is true, we can (mostly) define the JSOP diff format as a
>>> transformation from JSON Patch. That might be useful in order to avoid
>>> bikeshed discussions about syntax.
>>
>>
>> i agree that it would be useful if we could define JSOP diff as a
>> transformation
>> from JSON Patch.
>>
>> however, after skim-reading the JSON Patch draft i noticed the following
>> issues:
>>
>> - adding nested object trees doesn't seem to be explicitly covered,
>> e.g. +"/a/b/c" : { "foo" : "bar"}
>>   the draft only talks about manipulating non-object members of a
>> document.
>
>
> In
> <http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-01#section-4.1>,
> the example is setting an array as value. But I agree that it would be good
> to clarify the term "value".
>
>
>> - the draft does explicitly cover manipulating arrays of values.
>> that's not applicable
>>   to the mk data model (array values are not supported). furthermore,
>> there's
>>   no equivalent jcr operation.
>
>
> Ack. So this would be something that can be syntactically expressed in "JSOP
> Diff", but wouldn't be supported by the MK. Is this a problem?

i don't know yet, but probably not. we would have to clearly document
that restriction on the microkernel commit method.

>
>
>>> One open issue seems to be escaping inside pathString; if a JSON member
>>> contains a forward slash ("/"), how is it represented in a pathString?
>>>
>>> 1) We could define that it's not allowed to be in a member name, thus we
>>> don't need escaping, or
>>>
>>> 2) We could adopt the escaping syntax from JSON Pointer (now "^").
>>>
>>> 1) has the advantage of being simple.
>>>
>>> 2) has the advantage that it would work with generic JSON data, something
>>> I
>>> think we need to deal with if we want to use JSOP diff outside the MK
>>> work.
>>>
>>> Thoughts?
>>
>>
>> since forward slashes are not allowed in jcr names i guess it's not an
>> issue
>> for JSOP diff since "/" would need be encoded already according to the
>> jcr rules. i would prefer 1) but i am fine with either 1) or 2).
>
>
> My proposal is to start with 1) but to document the restriction; we can
> still introduce escaping later on if we find out that this is a problem.

agreed.

cheers
stefan

>
> Best regards, Julian

Mime
View raw message