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).
Michael
