Re: JSOP

[Michael Dürig <md...@apache.org>]

Taking to the dev list:

> Set currently is:
>
> SET      ::= "^" STRING ":" ATOM | ARRAY
>
> which seems to be the subset needed for setting JCR property values.
>
> Shouldn't we be able to overwrite nodes as well?
>
> Best regards, Julian

This is as intended: it is modeled after the JCR API: set is for setting 
property values and add is for adding properties and nodes. Add should 
fail if a property or node exists already.

Michael

Re: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

>Container format: something that wraps multiple single diffs into one
>file. Such as ZIP, multipart/*, or a JSON document that contains an
>array of diffs (something we could do easily if the diff format was JSON).

If you want to call it "container" or not is up to you.

The "@" notation is similar to the Unified diff format:
http://en.wikipedia.org/wiki/Diff#Unified_format - which supports multiple
files. Nobody every suggested to create a diff for each file separately,
and zip them or use multipart/*. It's always simply one file.


Also, both zip and multipart/* don't support json metadata. Then, zip and
multipart/* are vastly more complex solutions.

Regards,
Thomas

Re: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-11-30 07:54, Thomas Mueller wrote:
> Hi,
>
>> Why do we need multiple commits in one block?
>
> As I have already written, we need to get the information about multiple
> commits in one block for the method getJournal. See my previous mail.
>
>
>> Wouldn't it make more sense to either pipeline the requests, or define a
>> container format that can combine multiple diffs into one request?
>
> I have already proposed a container format, see my previous mail.
> What other container format do you propose?

Container format: something that wraps multiple single diffs into one 
file. Such as ZIP, multipart/*, or a JSON document that contains an 
array of diffs (something we could do easily if the diff format was JSON).

Best regards, Julian

Re: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

>Why do we need multiple commits in one block?

As I have already written, we need to get the information about multiple
commits in one block for the method getJournal. See my previous mail.


>Wouldn't it make more sense to either pipeline the requests, or define a
>container format that can combine multiple diffs into one request?

I have already proposed a container format, see my previous mail.
What other container format do you propose?

Regards,
Thomas

Re: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

>>Commit metadata is needed when you want to:
>>
>> * get multiple commits (diffs) in one block
>> * send multiple commits (diffs) in one block
>> ...

The Jackrabbit 3 MicroKernel currently only needs "get multiple commits in
one block". The "send" part is a possible extension for the future, but as
the format is exactly the same there is no harm.

Regards,
Thomas

Re: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-11-29 17:37, Thomas Mueller wrote:
> Hi,
>
> What is not on this wiki page yet - because it's not defined yet - is:
> "commit metadata". Commit metadata is needed when you want to:
>
> * get multiple commits (diffs) in one block
> * send multiple commits (diffs) in one block
> ...

Why do we need multiple commits in one block?

Wouldn't it make more sense to either pipeline the requests, or define a 
container format that can combine multiple diffs into one request?

Best regards, Julian

Re: JSOP extension points, was: JSOP

[Michael Dürig <md...@apache.org>]

On 5.12.11 14:54, Michael Dürig wrote:
>> Unless I'm missing something, a today's JSOP parsers will be unable to
>> parse future messages that contain an extension defined like the above,
>> as they won't know how to skip over it.
>>
>
> We could add an extension point to the compact syntax through the
> following production:
>
> EXTENSION ::= OP STRING ":" (OBJECT | ATOM | ARRAY)
>
> where OP is any single character except for +, ^, -, >, =, @ (and maybe
> some others to be defined).
>

FYI I added experimental support for above syntax.

Michael

Re: JSOP extension points, was: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-12-06 10:05, Thomas Mueller wrote:
> Hi,
>
>> The extension could indicate whether it's must-understand (such as
>> 'copy') or may-ignore (such as 'metadata').
>
> The 'may-ignore' extensions would have to be known when creating the
> specification.
>
> What about versions? The version to use is negotiated as follows:
>
> * client and server send the maximum version they support
> * they take the smaller of the two values in further communication
>
> In the case the server doesn't understand "copy node" (server version is
> 1), the client (client version 2) could send explicit add node commands,
> which are also understand in version 1, but are less efficient.
>
> Actually there could be multiple version number, for example a server and
> a client version, or a read and a write version (if the client version is
> too low, he might only be allowed to read but not write).

Version numbers may work when the format is defined by a single party.

Is it? Right now? Certainly not if we want to propose this as 
alternative to JSON-Patch (the IETF ID).

Best regards, Julian

Re: JSOP extension points, was: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

>The extension could indicate whether it's must-understand (such as
>'copy') or may-ignore (such as 'metadata').

The 'may-ignore' extensions would have to be known when creating the
specification.

What about versions? The version to use is negotiated as follows:

* client and server send the maximum version they support
* they take the smaller of the two values in further communication

In the case the server doesn't understand "copy node" (server version is
1), the client (client version 2) could send explicit add node commands,
which are also understand in version 1, but are less efficient.

Actually there could be multiple version number, for example a server and
a client version, or a read and a write version (if the client version is
too low, he might only be allowed to read but not write).


Regards,
Thomas

Re: JSOP extension points, was: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-12-06 09:17, Thomas Mueller wrote:
> Hi,
>
>> We could add an extension point to the compact syntax through the
>> following production:
>>
>> EXTENSION      ::= OP STRING ":" (OBJECT | ATOM | ARRAY)
>>
>> where OP is any single character except for +, ^, -,>, =, @ (and maybe
>> some others to be defined).
>
> That's a possible extension. The parser could support that. But I'm not
> sure if it's a good idea if items that are not understood are silently
> ignored. For example, if we add a new command "copy" as:
>
>      * "/from": "/to"
>
> (copies the node "/from" including all sub-nodes to a new node "/to"). Old
> implementations would silently ignore it? For proxies ignoring might work
> (forward whatever is not understood), but not for implementations (client
> side or server side).

The extension could indicate whether it's must-understand (such as 
'copy') or may-ignore (such as 'metadata').

Best regards, Julian

Re: JSOP extension points, was: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

>We could add an extension point to the compact syntax through the
>following production:
>
>EXTENSION      ::= OP STRING ":" (OBJECT | ATOM | ARRAY)
>
>where OP is any single character except for +, ^, -, >, =, @ (and maybe
>some others to be defined).

That's a possible extension. The parser could support that. But I'm not
sure if it's a good idea if items that are not understood are silently
ignored. For example, if we add a new command "copy" as:

    * "/from": "/to"

(copies the node "/from" including all sub-nodes to a new node "/to"). Old
implementations would silently ignore it? For proxies ignoring might work
(forward whatever is not understood), but not for implementations (client
side or server side).

Regards,
Thomas

Re: JSOP extension points, was: JSOP

[Michael Dürig <md...@apache.org>]

On 5.12.11 13:35, Julian Reschke wrote:
> This highlights a general problem with the compact syntax; it lacks an
> extension point.
>
> Unless I'm missing something, a today's JSOP parsers will be unable to
> parse future messages that contain an extension defined like the above,
> as they won't know how to skip over it.
>

We could add an extension point to the compact syntax through the 
following production:

EXTENSION      ::= OP STRING ":" (OBJECT | ATOM | ARRAY)

where OP is any single character except for +, ^, -, >, =, @ (and maybe 
some others to be defined).

Michael

Re: JSOP extension points, was: JSOP

[Michael Dürig <md...@apache.org>]

On 5.12.11 13:35, Julian Reschke wrote:
> This highlights a general problem with the compact syntax; it lacks an
> extension point.
>
> Unless I'm missing something, a today's JSOP parsers will be unable to
> parse future messages that contain an extension defined like the above,
> as they won't know how to skip over it.

Right, that's a valid point. I think we should find a way how extensions 
for the compact syntax could be handled - or switch to the IETF syntax. 
Otherwise we will probably lock ourselves in.

Michael

Re: JSOP extension points, was: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-12-05 15:02, Thomas Mueller wrote:
> Hi,
>
>> Unless I'm missing something, a today's JSOP parsers will be unable to
>> parse future messages that contain an extension defined like the above,
>> as they won't know how to skip over it.
>
> What we currently don't have, and probably should add, is a way to
> negotiate the format / protocol version (for example in the first message,
> similar to the "HTTP/1.1" in "GET / HTTP/1.1").
>
> But generally, parsers shouldn't silently skip over things they don't
> understand, except if it's explicitly defined to be implementation
> specific / optional (#pragma and such). Could you provide examples of
> languages that do support such extension points?

Most XML-based formats do; the same applies to JSON -- it's the "must 
ignore" pattern.

The "must understand" pattern makes it very hard to deploy new things, 
as you can't use it until each recipient understands it (this is why, 
for instance, the HTTP Expect header field is a big failure).

Best regards, Julian

Re: JSOP extension points, was: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-12-06 09:10, Thomas Mueller wrote:
> Hi,
>
>> JSON itself: if you specify that you are only interested in the property
>> "foo" in your json-based data, you will automatically skip any other
>> properties in the structure, without breaking any parsing.
>
> There are no extension points in the JSON syntax itself. With JSON syntax
> I mean the BNF of the JSON. The JSON syntax is strict, and that's OK.
>
>
> You are talking about the data. Sure, we could and should do that in our
> case as well. For example, we could say that the path "/:info/" should
> contain metadata information similar to the "information schema" in
> relational databases - if the given implementation supports it (meaning
> it's optional).

The difference here is that JSON and XML *are* extensible not at the 
syntax level, but the the logical level (by introducing new members / 
elements). The proposed JSOP diff format is not, because the grammar is 
optimized for the base operations.

Best regards, Julian

Re: JSOP extension points, was: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

>JSON itself: if you specify that you are only interested in the property
>"foo" in your json-based data, you will automatically skip any other
>properties in the structure, without breaking any parsing.

There are no extension points in the JSON syntax itself. With JSON syntax
I mean the BNF of the JSON. The JSON syntax is strict, and that's OK.


You are talking about the data. Sure, we could and should do that in our
case as well. For example, we could say that the path "/:info/" should
contain metadata information similar to the "information schema" in
relational databases - if the given implementation supports it (meaning
it's optional).

Regards,
Thomas

Re: JSOP extension points, was: JSOP

[Alexander Klimetschek <ak...@adobe.com>]

On 05.12.11 15:02, "Thomas Mueller" <mu...@adobe.com> wrote:
>Could you provide examples of
>languages that do support such extension points?

JSON itself: if you specify that you are only interested in the property
"foo" in your json-based data, you will automatically skip any other
properties in the structure, without breaking any parsing.

Cheers,
Alex

-- 
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

Re: JSOP extension points, was: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

>Unless I'm missing something, a today's JSOP parsers will be unable to
>parse future messages that contain an extension defined like the above,
>as they won't know how to skip over it.

What we currently don't have, and probably should add, is a way to
negotiate the format / protocol version (for example in the first message,
similar to the "HTTP/1.1" in "GET / HTTP/1.1").

But generally, parsers shouldn't silently skip over things they don't
understand, except if it's explicitly defined to be implementation
specific / optional (#pragma and such). Could you provide examples of
languages that do support such extension points?

Regards,
Thomas

JSOP extension points, was: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-11-29 17:37, Thomas Mueller wrote:
> Hi,
>
> What is not on this wiki page yet - because it's not defined yet - is:
> "commit metadata". Commit metadata is needed when you want to:
>
> * get multiple commits (diffs) in one block
> * send multiple commits (diffs) in one block
>
> As an example, see MicroKernel.getJournal() at
> http://svn.apache.org/repos/asf/jackrabbit/sandbox/microkernel/src/main/jav
> a/org/apache/jackrabbit/mk/api/MicroKernel.java
>
> This method is supposed to get multiple commits in one operation.
>
> I propose the following syntax:
>
> @ {"ts": 1322055029229, "msg": "New node 'hello'"}
> + "/hello": {}
> @ {"ts": 1322055029230, "msg": "New node 'world'"}
> + "/world": {}
>
> That means, the syntax for "commit metadata" is:
>
> METADATA ::= "@" OBJECT
> ...

This highlights a general problem with the compact syntax; it lacks an 
extension point.

Unless I'm missing something, a today's JSOP parsers will be unable to 
parse future messages that contain an extension defined like the above, 
as they won't know how to skip over it.

Best regards, Julian

Re: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

What is not on this wiki page yet - because it's not defined yet - is:
"commit metadata". Commit metadata is needed when you want to:

* get multiple commits (diffs) in one block
* send multiple commits (diffs) in one block

As an example, see MicroKernel.getJournal() at
http://svn.apache.org/repos/asf/jackrabbit/sandbox/microkernel/src/main/jav
a/org/apache/jackrabbit/mk/api/MicroKernel.java

This method is supposed to get multiple commits in one operation.

I propose the following syntax:

@ {"ts": 1322055029229, "msg": "New node 'hello'"}
+ "/hello": {}
@ {"ts": 1322055029230, "msg": "New node 'world'"}
+ "/world": {}

That means, the syntax for "commit metadata" is:

METADATA ::= "@" OBJECT

Regards,

Thomas

Re: JSOP

[Michael Dürig <md...@apache.org>]

> We still suffer from an agreed-upon set of design goals and constraints.

Ack. That's probably why we have several incompatible ad-hoc 
implementation.

>
> If we want to *standardize* something, we need to abstract away things
> specific to JCR. Also, we need either to get the features we need into
> the common formats (such as support for tagging batches or adding
> tests), *or* need to make sure extension points are in place.
>
> It would also be useful to understand why we apparently have three
> different implementations (two in Jackrabbit, one in Sling?), and what
> we need to do make the compatible. We probably can't make them a single
> implementation, but the fact that we have multiple "similar" diff
> formats and implementations gives me headaches.

Same here. We should really try to consolidate these into one common 
format. For the why see above.

Michael

>
> Best regards, Julian

Re: JSOP

[Julian Reschke <jr...@adobe.com>]

On 30.11.2011 15:40, Thomas Mueller wrote:
> Hi,
>
>> I happen to disagree with that, and the initial work that has been done
>> seems to agree with me.
>
> I see.
>
>> For the record: I'd be totally ok with minting a set of new names,
>> "JSOP" for me is to close to "JSON-P" with which we certainly do not
>> want to be confused.
>
> In my view, JSOP stands for "JSON Patch". I believe it would be confusing
> if JSOP is a protocol, given it only differs in one letter from the format
> JSON.
>
> What about a new term for the protocol, for example HTTP-JSON or HTTP-JSOP.

-1 on changing what JSOP means.

+1 on getting rid of the term JSOP altogether.

Best regards, Julian

Re: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

>I happen to disagree with that, and the initial work that has been done
>seems to agree with me.

I see.

>For the record: I'd be totally ok with minting a set of new names,
>"JSOP" for me is to close to "JSON-P" with which we certainly do not
>want to be confused.

In my view, JSOP stands for "JSON Patch". I believe it would be confusing
if JSOP is a protocol, given it only differs in one letter from the format
JSON.

What about a new term for the protocol, for example HTTP-JSON or HTTP-JSOP.

Regards,
Thomas

Re: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-11-30 15:02, Thomas Mueller wrote:
> Hi,
>
> JSON is a format. It would confuse people if JSOP is a protocol and not a
> format.

I happen to disagree with that, and the initial work that has been done 
seems to agree with me.

For the record: I'd be totally ok with minting a set of new names, 
"JSOP" for me is to close to "JSON-P" with which we certainly do not 
want to be confused.

Best regards, Julian

Re: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

JSON is a format. It would confuse people if JSOP is a protocol and not a
format.

Regards,
Thomas



On 11/30/11 2:55 PM, "julian.reschke@gmx.de" <ju...@gmx.de> wrote:

>On 2011-11-30 14:46, Thomas Mueller wrote:
>> Hi,
>>
>>> Are we defining a protocol or an API?
>>
>> A format: the JSOP format. For me that's the most important item. I
>>don't
>
>OK, we need to agree on terminology.
>
>The diff format is just one building block for "JSOP".
>
>> ...
>
>Best regards, Julian

Re: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-11-30 14:46, Thomas Mueller wrote:
> Hi,
>
>> Are we defining a protocol or an API?
>
> A format: the JSOP format. For me that's the most important item. I don't

OK, we need to agree on terminology.

The diff format is just one building block for "JSOP".

> ...

Best regards, Julian

Re: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

>Are we defining a protocol or an API?

A format: the JSOP format. For me that's the most important item. I don't
care too much about the protocol part - actually it doesn't need to be
standardized in my view (the HTTP protocol is sufficient). And the
MicroKernel API doesn't need to be standardized either (at least not at
the moment).

>My understanding was that we're
>talking about a remoting protocol that, yes, should use HTTP.

For Jackrabbit 3, the MicroKernel API is called from within the same
process, from the same computer, or remotely.

Regards,
Thomas

Re: JSOP

[Julian Reschke <jr...@adobe.com>]

On 30.11.2011 14:20, Thomas Mueller wrote:
> Hi,
>
>> If the task is "define a patch format for use over HTTP Patch", then
>> yes, we can assume HTTP is there.
>
> Yes. But for Jackrabbit 3, we want to define an API that doesn't require
> HTTP (or ZIP). Currently it's a Java API, but we might extend it to other
> programming languages such a PHP, C#, and C.

Are we defining a protocol or an API? My understanding was that we're 
talking about a remoting protocol that, yes, should use HTTP.

If the microkernel work has adopted a certain building block (a diff 
format) that's fine, but it shouldn't mean that this work should drive 
the definition of the protocol (which is something we would commit to 
support for remote access for a long time).

>> We still suffer from an agreed-upon set of design goals and constraints.
>
> In my view, the goal is to standardize a format that supports the features
> required by the current use cases. Probably the most advanced use case is
> the Jackrabbit 3 MicroKernel API. Also, the features required by the
> MicroKernel API should be supported. The format can't rely on a HTTP
> binding.

It seems to me then that we're talking about different things.

>> If we want to *standardize* something, we need to abstract away things
>> specific to JCR.
>
> The standard must not refer to JCR, but the standard should support the
> features required by JCR. Is this what you mean if you write "abstract
> away"?

With "abstract away" I meant: we need to map JCR features to generic 
things, like addressing JCR nodes through HTTP (so that we have things 
we can apply GET, PUT, PATCH to) and mapping JCR node trees to JSON (so 
that having a patch format for JSON is something we can actually apply 
to our remoting cases).

>> Also, we need either to get the features we need into
>> the common formats (such as support for tagging batches or adding
>> tests), *or* need to make sure extension points are in place.
>
> I agree. Extension points could be documented as optional features.

Actually, the *extension point* needs to be required, in that recipients 
do not fail when it is used. Which brings us to must-understand vs 
must-ignore.

Best regards, Julian

Re: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

>If the task is "define a patch format for use over HTTP Patch", then
>yes, we can assume HTTP is there.

Yes. But for Jackrabbit 3, we want to define an API that doesn't require
HTTP (or ZIP). Currently it's a Java API, but we might extend it to other
programming languages such a PHP, C#, and C.

>We still suffer from an agreed-upon set of design goals and constraints.

In my view, the goal is to standardize a format that supports the features
required by the current use cases. Probably the most advanced use case is
the Jackrabbit 3 MicroKernel API. Also, the features required by the
MicroKernel API should be supported. The format can't rely on a HTTP
binding.

>If we want to *standardize* something, we need to abstract away things
>specific to JCR.

The standard must not refer to JCR, but the standard should support the
features required by JCR. Is this what you mean if you write "abstract
away"?
 
> Also, we need either to get the features we need into
>the common formats (such as support for tagging batches or adding
>tests), *or* need to make sure extension points are in place.

I agree. Extension points could be documented as optional features.

Regards,
Thomas

Re: JSOP

[Julian Reschke <jr...@adobe.com>]

On 30.11.2011 13:19, Thomas Mueller wrote:
> Hi,
>
>> I agree that this might be useful, but a simpler approach is to use
>> HTTP's If-Match header. Of course that requires having a sane strategy
>> to compute ETags.
>
> You are mixing the binding (HTTP) with the format (JSOP).
>
> You can't assume HTTP is used.

Well, it depends where we're coming from.

If the task is "define a patch format for use over HTTP Patch", then 
yes, we can assume HTTP is there.

We still suffer from an agreed-upon set of design goals and constraints.

If we want to *standardize* something, we need to abstract away things 
specific to JCR. Also, we need either to get the features we need into 
the common formats (such as support for tagging batches or adding 
tests), *or* need to make sure extension points are in place.

It would also be useful to understand why we apparently have three 
different implementations (two in Jackrabbit, one in Sling?), and what 
we need to do make the compatible. We probably can't make them a single 
implementation, but the fact that we have multiple "similar" diff 
formats and implementations gives me headaches.

Best regards, Julian

Re: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

>I agree that this might be useful, but a simpler approach is to use
>HTTP's If-Match header. Of course that requires having a sane strategy
>to compute ETags.

You are mixing the binding (HTTP) with the format (JSOP).

You can't assume HTTP is used.

Regards,
Thomas

Re: JSOP

[Julian Reschke <jr...@adobe.com>]

On 30.11.2011 09:44, Thomas Mueller wrote:
> Hi,
>
> Another proposed addition is a 'test' line:
>
> = "/swiss/lx 38/availableSeats": 100
> ^ "/swiss/lx 38/availableSeats": 99
>
> The meaning of the 'test' line (the one starting with '=') is: before
> applying the rest of patch, the value is verified. If it does not match,
> then the subsequent line(s) will not be applied. The exact semantics are
> not yet defined however and will most likely be implementation specific -
> for example it is undefined whether a mismatch will result in an exception
> or not, and whether all following lines of the commit belong to the same
> atomic operation or not.
>
> This addition allows to construct atomic commits - see also
> http://en.wikipedia.org/wiki/Test-and-set

I agree that this might be useful, but a simpler approach is to use 
HTTP's If-Match header. Of course that requires having a sane strategy 
to compute ETags.

Best regards, Julian

Re: JSOP

[Thomas Mueller <mu...@adobe.com>]

Hi,

Another proposed addition is a 'test' line:

= "/swiss/lx 38/availableSeats": 100
^ "/swiss/lx 38/availableSeats": 99

The meaning of the 'test' line (the one starting with '=') is: before
applying the rest of patch, the value is verified. If it does not match,
then the subsequent line(s) will not be applied. The exact semantics are
not yet defined however and will most likely be implementation specific -
for example it is undefined whether a mismatch will result in an exception
or not, and whether all following lines of the commit belong to the same
atomic operation or not.

This addition allows to construct atomic commits - see also
http://en.wikipedia.org/wiki/Test-and-set

Regards,
Thomas

Re: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-11-29 19:24, Michael Dürig wrote:
>
>
> On 29.11.11 17:46, Julian Reschke wrote:
>>>>>> Internally, SET can always be implemented as atomic variant of
>>>>>> REMOVE-then-ADD.
>>>>>
>>>>> In general yes. However for the Jackrabbit Microkernel use case this
>>>>> becomes troublesome wrt. observation.
>>>>
>>>> The diff format makes no promises about the observable events, so I
>>>> wouldn't worry about that.
>>>
>>> What I'm worrying about is that when the format doesn't allow us to
>>> implement JCR observation, we won't use it but rather a derivative of
>>> it.
>>
>> Could you elaborate what the problem is?
>
> The Microkernel uses the JSOP diff format to report changes in the
> repository (see Microkernel.getJournal() [1]. The upper layers use this
> change log to create JCR observation events. So for properties, there
> needs to be a way to tell 'remove' followed by 'add' apart from 'set' in
> order to create the correct JCR events.

Understood. But I don't think the proposed change does any harm here.

Best regards, Julian

Re: JSOP

[Michael Dürig <md...@apache.org>]

On 29.11.11 17:46, Julian Reschke wrote:
>>>>> Internally, SET can always be implemented as atomic variant of
>>>>> REMOVE-then-ADD.
>>>>
>>>> In general yes. However for the Jackrabbit Microkernel use case this
>>>> becomes troublesome wrt. observation.
>>>
>>> The diff format makes no promises about the observable events, so I
>>> wouldn't worry about that.
>>
>> What I'm worrying about is that when the format doesn't allow us to
>> implement JCR observation, we won't use it but rather a derivative of it.
>
> Could you elaborate what the problem is?

The Microkernel uses the JSOP diff format to report changes in the 
repository (see Microkernel.getJournal() [1]. The upper layers use this 
change log to create JCR observation events. So for properties, there 
needs to be a way to tell 'remove' followed by 'add' apart from 'set' in 
order to create the correct JCR events.

Michael

[1] 
http://svn.apache.org/viewvc/jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/api/MicroKernel.java?view=markup

Re: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-11-29 18:41, Michael Dürig wrote:
>
>
>>>> Internally, SET can always be implemented as atomic variant of
>>>> REMOVE-then-ADD.
>>>
>>> In general yes. However for the Jackrabbit Microkernel use case this
>>> becomes troublesome wrt. observation.
>>
>> The diff format makes no promises about the observable events, so I
>> wouldn't worry about that.
>
> What I'm worrying about is that when the format doesn't allow us to
> implement JCR observation, we won't use it but rather a derivative of it.

Could you elaborate what the problem is?

Best regards, Julian

Re: JSOP

[Michael Dürig <md...@apache.org>]

>>> Internally, SET can always be implemented as atomic variant of
>>> REMOVE-then-ADD.
>>
>> In general yes. However for the Jackrabbit Microkernel use case this
>> becomes troublesome wrt. observation.
>
> The diff format makes no promises about the observable events, so I
> wouldn't worry about that.

What I'm worrying about is that when the format doesn't allow us to 
implement JCR observation, we won't use it but rather a derivative of it.

Michael

Re: JSOP

[Julian Reschke <ju...@gmx.de>]

On 2011-11-29 18:08, Michael Dürig wrote:
> ...
> Yes agreed. Just note that the format described on the Wiki page started
> out as "JSOP Diff for the Jackrabbit Microkernel". That's why some
> things might not be as general as they could.
> ...

Yep. *If* we want to define a generic format in addition to JSON-Patch, 
we have to loosen the dependency on JCR.

>> Internally, SET can always be implemented as atomic variant of
>> REMOVE-then-ADD.
>
> In general yes. However for the Jackrabbit Microkernel use case this
> becomes troublesome wrt. observation.

The diff format makes no promises about the observable events, so I 
wouldn't worry about that.

Best regards, Julian

Re: JSOP

[Michael Dürig <md...@apache.org>]

>>
>>> Set currently is:
>>>
>>> SET ::= "^" STRING ":" ATOM | ARRAY
>>>
>>> which seems to be the subset needed for setting JCR property values.
>>>
>>> Shouldn't we be able to overwrite nodes as well?
>>>
>>> Best regards, Julian
>>
>> This is as intended: it is modeled after the JCR API: set is for setting
>> property values and add is for adding properties and nodes. Add should
>> fail if a property or node exists already.
>
> Yes. But just because the JCR API doesn't have "set" for nodes doesn't
> mean it's not a useful operation; and if we want to define a data format
> that is not specific to JCR remoting then the restriction doesn't seem
> to make sense.

Yes agreed. Just note that the format described on the Wiki page started 
out as "JSOP Diff for the Jackrabbit Microkernel". That's why some 
things might not be as general as they could.

> Internally, SET can always be implemented as atomic variant of
> REMOVE-then-ADD.

In general yes. However for the Jackrabbit Microkernel use case this 
becomes troublesome wrt. observation.

Michael

Re: JSOP

[Julian Reschke <jr...@adobe.com>]

On 29.11.2011 17:05, Michael Dürig wrote:
>
> Taking to the dev list:
>
>> Set currently is:
>>
>> SET      ::= "^" STRING ":" ATOM | ARRAY
>>
>> which seems to be the subset needed for setting JCR property values.
>>
>> Shouldn't we be able to overwrite nodes as well?
>>
>> Best regards, Julian
>
> This is as intended: it is modeled after the JCR API: set is for setting
> property values and add is for adding properties and nodes. Add should
> fail if a property or node exists already.

Yes. But just because the JCR API doesn't have "set" for nodes doesn't 
mean it's not a useful operation; and if we want to define a data format 
that is not specific to JCR remoting then the restriction doesn't seem 
to make sense.

Internally, SET can always be implemented as atomic variant of 
REMOVE-then-ADD.

Best regards, Julian