You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Felix Meschberger <fm...@adobe.com> on 2011/11/02 17:07:16 UTC
Re: [Jackrabbit Wiki] Update of "Jsop" by MichaelDürig
Hi,
Thanks Thomas and Michael for documenting your JSOP use.
I have one comment:
> + DIFFS ::= (ADD | SET | REMOVE | MOVE)*
> + ADD ::= "+" STRING ":" (OBJECT | ATOM)
> + SET ::= "^" STRING ":" ATOM
> + REMOVE ::= "-" STRING
I see there is ADD support for properties but no REMOVE support. I think ADD support is not needed, because SET does it all. This not only makes the syntax cleaner but also its use.
If we keep ADD support for properties, we would -- for symmetry reasons -- have to add REMOVE support for properties. But this is not possible (since properties and nodes can have the same name). But then REMOVE support for properties would not help anything, since setting a property to null is the same.
I look at this from the perspective of converting a JSOP document (or string or text or file or HTTP request) into a series of JCR API calls. In such a scenario, I would have easy support for SET and REMOVE but would have two issues for supporting ADD:
(1) I would have to inspect the argument to ADD to find out whether it is an addNode or setProperty call
(2) I would have to handle SET and ADD-for-property with the same setProperty call
This feels wrong.
Regards
Felix
PS: I seem to remember the ancient JCR 1.0 days where there was a discussion on whether we need addProperty and setProperty or setProperty would be just enough..... ;-)
Re: [Jackrabbit Wiki] Update of "Jsop" by MichaelDürig
Posted by Michael Dürig <md...@apache.org>.
>> The intended use is not only for HTTP calls but rather also for HTTP replies. In the case of a HTTP reply carrying a change log, how would you distinguish setProperty from adProperty? I.e. generate the correct JCR observation events from that change log?
>
> Right. I wonder, why this would be of interest ? (and yes I know that there is a PROPERTY_ADDED and a PROPERTY_CHANGED event type in observation, but ...)
Well we might want to support the JCR spec with Jackrabbit. That's what
its all about I guess.
Michael
Re: [Jackrabbit Wiki] Update of "Jsop" by MichaelDürig
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>(and yes I know that there is a PROPERTY_ADDED and a PROPERTY_CHANGED
>event type in observation, but ...)
Yes, the JCR API requires this distinction. Not supporting the JCR API
would be bad. Supporting the JCR API - but having a very very slow
implementation - would also be bad.
One option might be to change the JCR API. As far as I know, the next
generation JCR API is not yet finalized, so we could discuss this issue
there: http://java.net/projects/jsr-333/ - Felix, could you add a issue or
(if that's easier) tell me what I should write (I have an account).
Regards,
Thomas
Re: [Jackrabbit Wiki] Update of "Jsop" by MichaelDürig
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am 02.11.2011 um 17:22 schrieb Michael Dürig:
>
>
> On 2.11.11 16:07, Felix Meschberger wrote:
>> Hi,
>>
>> Thanks Thomas and Michael for documenting your JSOP use.
>>
>> I have one comment:
>>
>>> + DIFFS ::= (ADD | SET | REMOVE | MOVE)*
>>> + ADD ::= "+" STRING ":" (OBJECT | ATOM)
>>> + SET ::= "^" STRING ":" ATOM
>>> + REMOVE ::= "-" STRING
>>
>> I see there is ADD support for properties but no REMOVE support. I think ADD support is not needed, because SET does it all. This not only makes the syntax cleaner but also its use.
>>
>> If we keep ADD support for properties, we would -- for symmetry reasons -- have to add REMOVE support for properties. But this is not possible (since properties and nodes can have the same name). But then REMOVE support for properties would not help anything, since setting a property to null is the same.
>>
>> I look at this from the perspective of converting a JSOP document (or string or text or file or HTTP request) into a series of JCR API calls. In such a scenario, I would have easy support for SET and REMOVE but would have two issues for supporting ADD:
>> (1) I would have to inspect the argument to ADD to find out whether it is an addNode or setProperty call
>> (2) I would have to handle SET and ADD-for-property with the same setProperty call
>
> The intended use is not only for HTTP calls but rather also for HTTP replies. In the case of a HTTP reply carrying a change log, how would you distinguish setProperty from adProperty? I.e. generate the correct JCR observation events from that change log?
Right. I wonder, why this would be of interest ? (and yes I know that there is a PROPERTY_ADDED and a PROPERTY_CHANGED event type in observation, but ...)
Regards
Felix
>
> Michael
Re: [Jackrabbit Wiki] Update of "Jsop" by MichaelDürig
Posted by Michael Dürig <md...@apache.org>.
On 2.11.11 16:07, Felix Meschberger wrote:
> Hi,
>
> Thanks Thomas and Michael for documenting your JSOP use.
>
> I have one comment:
>
>> + DIFFS ::= (ADD | SET | REMOVE | MOVE)*
>> + ADD ::= "+" STRING ":" (OBJECT | ATOM)
>> + SET ::= "^" STRING ":" ATOM
>> + REMOVE ::= "-" STRING
>
> I see there is ADD support for properties but no REMOVE support. I think ADD support is not needed, because SET does it all. This not only makes the syntax cleaner but also its use.
>
> If we keep ADD support for properties, we would -- for symmetry reasons -- have to add REMOVE support for properties. But this is not possible (since properties and nodes can have the same name). But then REMOVE support for properties would not help anything, since setting a property to null is the same.
>
> I look at this from the perspective of converting a JSOP document (or string or text or file or HTTP request) into a series of JCR API calls. In such a scenario, I would have easy support for SET and REMOVE but would have two issues for supporting ADD:
> (1) I would have to inspect the argument to ADD to find out whether it is an addNode or setProperty call
> (2) I would have to handle SET and ADD-for-property with the same setProperty call
The intended use is not only for HTTP calls but rather also for HTTP
replies. In the case of a HTTP reply carrying a change log, how would
you distinguish setProperty from adProperty? I.e. generate the correct
JCR observation events from that change log?
Michael
Re: [Jackrabbit Wiki] Update of "Jsop" by MichaelDürig
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>I look at this from the perspective of converting a JSOP document (or
>string or text or file or HTTP request) into a series of JCR API calls.
>In such a scenario, I would have easy support for SET and REMOVE but
>would have two issues for supporting ADD:
>(1) I would have to inspect the argument to ADD to find out whether it is
>an addNode or setProperty call
Yes. You have to do that same when adding a node:
+ "/test": { "x": 1, "y": {} }
here "x" is a property and "y" is a node. The only way to decide which is
which is by looking at what comes after the ":".
>(2) I would have to handle SET and ADD-for-property with the same
>setProperty call
Yes, why is this a problem?
>This feels wrong.
I don't see anything wrong actually.
Regards,
Thomas