jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: [Jackrabbit Wiki] Update of "Jsop" by ThomasMueller
Date Fri, 09 Dec 2011 11:23:54 GMT
On 9.12.11 11:09, Julian Reschke wrote:
>>> Not sure this is a good idea, as long as we pretend that this format has
>>> something to do with JSON. The main purpose of JSON is that the objects
>>> can be instantiated again in JavaScript, at which point the ordering
>>> becomes undefined.
>> If one possible *client* isn't interested in the order, then that's not a
>> problem. The problem is that the *server* should keep the order, so that
> The problem here is that we pretend that part of the syntax use JSON,
> which implies you can use off-the-shelve JSON code to produce or consume
> these parts. But you can't if you pretend that JSON object members have
> an ordering.
>> clients that are interested in the order can work. Otherwise "move" with
>> "before" / "after" isn't that meaningful.
> For now, JSON Patch allows moving *to* locations that can be identified
> by JSON Pointers, so within the hierarchy and within arrays, but that
> doesn't affect the ordering of non-array members.
>> What about making it an optional feature ("may")? It still possible for a
>> client to define the order using many "move" calls, but it's a bit
>> strange
>> I have admit:
>> + "/test": {"a": {}, "b": {}, "c": {}}
>>> "/test/b": { "after": "/test/a" }
>>> "/test/c": { "after": "/test/b" }
>> This will ensure the order is "a", "b", "c".
> -1, if this is supposed to be a generic format for use outside
> Jackrabbit. But I'm starting to believe it's not.
> To make it a generic format, it needs to make sense in terms of mapping
> a JCR hierarchy to JSON, and operations *applied* to JSON.
> *If* we want to support ordered collections, than the JSON mapping
> should contain additional information on the sort order of the members.
> Like this:
> {"a": {}, "b": {}, "c": {}, "{somejcrrelateduri}sortorder": [ "a", "b",
> "c" ] }

Ack. This would make the order explicit where it is required. It'd also 
nicely map to JCR's orderable attribute.

Besides, this might also better mach upcoming JCR implementations: if we 
want to support huge child node lists *and* have them orderable, we will 
most likely have to do away with the linked hash map we are using at the 
moment and rather store the permutation along with the child node list 
(much like an index).


View raw message