Re: [JSON] Stable Child Resource Order
Hi,
Am Donnerstag, den 07.04.2011, 20:46 +0100 schrieb Eric Norman:
Yes, but if order is important it seems more correct to send an array. And
adding a psuedo 'order' property isn't backward compatible either.
I see, but ...
As has been said, the current JSON export has the nice side-effect of
being an exact view on the Sling Resource Tree (the repository mostly,
but not exclusively). I think this is one of the value propositions of
our JSON export.
So, I would like to keep this.
Adding a new property :order (remark the leading colon) on request, we
can provide the ordering information in a special property which
should/cannot be mistaken for a regular property (because the leading
colon would be an illegale JCR name).
Also, the :order would only be sent on-request.
So, I think we are backwards compatible and the workaround IMHO is
acceptable.
Regards
Felix
On Thu, Apr 7, 2011 at 11:26 AM, Tobias Bocanegra tri...@adobe.com wrote:
On Thu, Apr 7, 2011 at 10:38 AM, Eric Norman eric.d.nor...@gmail.com
wrote:
why not just render the ordered child nodes as a json array?
that's another way, yes. but then you need to transport the resource
name in a special property. eg:
{
name: foo,
properties: {
},
children: [
{
name:child1,
properties: { ... },
children : [ ...]
},
{
...
}
]
but this would not be backward compatible and is more complex, too.
regards, toby
Re: [JSON] Stable Child Resource Order
On 11.04.11 05:50, Felix Meschberger fmesc...@adobe.com wrote: Am Freitag, den 08.04.2011, 12:04 +0100 schrieb Alexander Klimetschek: On 08.04.11 08:01, Carsten Ziegeler cziege...@apache.org wrote: maps rarely have an order regardless of the language. A linked map is not an unusual data structure. As Tobi noted, WCM/CMS is a prominent use case. Yes, but: the Map interface itself has no defined order: Some map implementations, like the TreeMap class, make specific guarantees as to their order; others, like the HashMap class, do not. So, if you encounter a Map (not a TreeMap or LinkedHashMap), you must not depend on any key ordering ... And most Map implementations used are in fact neither TreeMap nor LinkedHashMap. Yes, I agree. However,this is just the way the abstractions in the Java Collections API have been designed. With unusual data structure I was actually meaning use-cases rather than specific data structure concepts in languages such as Java. For a protocol-level data structure you want to be language-independent, and focus on what is needed. Not sure if I wrote that already: it is really unfortunate that the order is excluded from JSON (which only comes from the ECMAscript definition) when the serialization format already keeps the ordering so easily. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
While I see the reasons behind just adding an order property, I agree with Eric that if you want to have an ordering use an array - maps rarely have an order regardless of the language. This is about adding a new format, so both client and server needs to implement this - therefore I think we're really free to do the right thing. I don't see the need that the enhanced format is nearly the same as the old one. Regards Carsten Alexander Klimetschek wrote On 07.04.11 21:47, Eric Norman eric.d.nor...@gmail.com wrote: Is there any reason why you can't just make a custom script to output whatever JSON format you want? I'm not convinced this has usefulness outside your use case that would warrant changing the generic format. That's what we are discussing: how to integrate it as simple as possible without breaking things ;-) Regards, Alex -- Carsten Ziegeler cziege...@apache.org
Re: [JSON] Stable Child Resource Order
well, as alex said, the format is quite cool and very useful when it's
used in an ecma script environment. and i guess the order is not often
used. and if you wish to iterate, then you can just use the
child-names array, eg:
for (var name in obj[:child-names]) {
var child = obj[name];
}
regards, toby
On Thu, Apr 7, 2011 at 11:01 PM, Carsten Ziegeler cziege...@apache.org wrote:
While I see the reasons behind just adding an order property, I agree
with Eric that if you want to have an ordering use an array - maps
rarely have an order regardless of the language.
This is about adding a new format, so both client and server needs to
implement this - therefore I think we're really free to do the right
thing. I don't see the need that the enhanced format is nearly the same
as the old one.
Regards
Carsten
Alexander Klimetschek wrote
On 07.04.11 21:47, Eric Norman eric.d.nor...@gmail.com wrote:
Is there any reason why you can't just make a custom script to output
whatever JSON format you want? I'm not convinced this has usefulness
outside your use case that would warrant changing the generic format.
That's what we are discussing: how to integrate it as simple as possible
without breaking things ;-)
Regards,
Alex
--
Carsten Ziegeler
cziege...@apache.org
Re: [JSON] Stable Child Resource Order
Tobias Bocanegra wrote well, as alex said, the format is quite cool and very useful when it's used in an ecma script environment. and i guess the order is not often used. Well...if the order is not used, the old format is perfect, right? :) and if you wish to iterate, then you can just use the child-names array, eg: Yes, but iterating over an array is easy as well :) So, it boils down to: - abusing a map with a special order property vs - using an array with a special name property :) Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [JSON] Stable Child Resource Order
On 08.04.11 08:01, Carsten Ziegeler cziege...@apache.org wrote: maps rarely have an order regardless of the language. A linked map is not an unusual data structure. As Tobi noted, WCM/CMS is a prominent use case. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
[JSON] Stable Child Resource Order
hi,
the JSON serialization that sling uses to generate json responses
assumes that the consumer creates a object representation that has a
stable child object ordering. although this is not mandated neither by
JSON [0] nor by ECMA [1] most of the ecma runtimes have stable child
objects. but for example the default org.json.JSONObject uses a plain
HashMap for the child objects, that's why sling has an extended
version that uses a LinkedHashMap.
i recently played with the JSONDecoder in Flash which just creates
plain AS Objects, which don't have a stable order, so i had to create
an own decoder that feeds a specialized AS JSONObject. I assume that
other runtimes (.NET, PHP, etc) might suffer from the same problem.
see also [2] and [3] that talk about that.
especially when dealing with WCM content, where the ordering is
important (order of paragraphs, order of child documents, etc), this
might be a problem that such implementations can't rely on their
default json lib, when they want to access a resource tree remotely.
this all leads to the question, if the JSON response of sling should
be extended to alleviate the transport of a stable child resource
ordering. the probably simplest and backward compatible extension
could be to additionally include an array with the child resource
names, for example:
{
p1: hello world,
a: { ... },
b: { ... },
*: [a, b]
}
the special array * would contain the names of the child resources
in the order provided by the resource resolver. the special name *
should minimize the risk for collisions with existing nv pairs. also
note, that the order of the properties is not relevant to clients
(as, for example, it is not given for JCR properties, xml attributes,
nv pairs in java properties files, etc).
the resource resolver could even be extended to expose the information
about if child resource ordering is given at all (for example only jcr
nodes with 'orderable child nodes' have this behavior). if the oder
can not be provided by the underlying system, the * array should be
omitted.
including this array per default would generate some overhead by
increasing response sizes and client memory consumption and also
decreasing decoding performance. so it might makes sense to either
make it configurable, or to deduce it somehow from the request
(special header, special extension, special selector). also, i would
only include it, if the depth level is high enough to already include
the child resources (e.g. foo.0.json would not include the * array).
WDYT ?
regards, toby
[0] http://www.json.org/javadoc/org/json/JSONObject.html (A JSONObject
is an unordered collection of name/value pairs...)
[1] http://interglacial.com/javascript_spec/a-4.html#a-4.3.3
[2]
http://stackoverflow.com/questions/280713/elements-order-for-in-loop-in-javascript
[3] http://old.nabble.com/iteration-order-for-Object-td31120998.html
Re: [JSON] Stable Child Resource Order
Hi,
Am Donnerstag, den 07.04.2011, 06:47 +0100 schrieb Tobias Bocanegra:
hi,
the JSON serialization that sling uses to generate json responses
assumes that the consumer creates a object representation that has a
stable child object ordering. although this is not mandated neither by
JSON [0] nor by ECMA [1]
To be clear: The ECMAScript standard explicitly states, that there is
*no* order to be assumed amongst the properties. As a consequence JSON
(and the JSON library we use) do *not* guarantee an order.
most of the ecma runtimes have stable child
objects.
which is legal according to the spec but leads to false assumptions,
unfortunately
but for example the default org.json.JSONObject uses a plain
HashMap for the child objects, that's why sling has an extended
version that uses a LinkedHashMap.
i recently played with the JSONDecoder in Flash which just creates
plain AS Objects, which don't have a stable order, so i had to create
an own decoder that feeds a specialized AS JSONObject. I assume that
other runtimes (.NET, PHP, etc) might suffer from the same problem.
No, they don't suffer from the problem. They are perfectly right. We
suffer by assuming an order.
see also [2] and [3] that talk about that.
especially when dealing with WCM content, where the ordering is
important (order of paragraphs, order of child documents, etc), this
might be a problem that such implementations can't rely on their
Again (sorry): We should not rely because the expectations may and will
fail... (as we now see in reality, and I have heard some browser vendors
even don't have ordered properties any longer ...)
default json lib, when they want to access a resource tree remotely.
this all leads to the question, if the JSON response of sling should
be extended to alleviate the transport of a stable child resource
ordering. the probably simplest and backward compatible extension
could be to additionally include an array with the child resource
names, for example:
{
p1: hello world,
a: { ... },
b: { ... },
*: [a, b]
}
the special array * would contain the names of the child resources
in the order provided by the resource resolver. the special name *
should minimize the risk for collisions with existing nv pairs. also
note, that the order of the properties is not relevant to clients
(as, for example, it is not given for JCR properties, xml attributes,
nv pairs in java properties files, etc).
the resource resolver could even be extended to expose the information
about if child resource ordering is given at all (for example only jcr
nodes with 'orderable child nodes' have this behavior). if the oder
can not be provided by the underlying system, the * array should be
omitted.
including this array per default would generate some overhead by
increasing response sizes and client memory consumption and also
decreasing decoding performance. so it might makes sense to either
make it configurable, or to deduce it somehow from the request
(special header, special extension, special selector). also, i would
only include it, if the depth level is high enough to already include
the child resources (e.g. foo.0.json would not include the * array).
WDYT ?
I like the idea of a special property and I like the special character
used. Maybe we could just use a regular illegal property name like
:child-node-order or :sling:child-node-order instead of a single
character.
Using the colon prefix would also make sure, that such a property if
sent back to the Sling POST Servlet would just be ignored.
I am not so much concerned with performance (I would assume the ordering
information overhead is minimal). I am more concerned with backwards
compatibility. Unfortunately existing clients will not expect additional
properties and thus side effects may happen if we just add them. So in
the interest of stability, I would suggest we add a required selector to
get back the child node order property.
Regarding information on supported child node ordering: I would assume
that we could add such information to the ResourceMetaData of JCR Node
Resources.
To conclude:
+1 to extend JcrNodeResource to provide the orderable child node
attribute of the node type to the ResourceMetaData
+1 to optionally provide a synthetic child node order property
+1 to requiring a new selector to request the child node order
property
+1 to omit the child node order property if the parent node does
not support child node ordering (as indicated by the
ResourceMetaData property).
Regards
Felix
regards, toby
[0] http://www.json.org/javadoc/org/json/JSONObject.html (A JSONObject
is an unordered collection of name/value pairs...)
[1] http://interglacial.com/javascript_spec/a-4.html#a-4.3.3
[2]
http://stackoverflow.com/questions/280713/elements-order-for-in-loop-in-javascript
[3] http://old.nabble.com/iteration-order-for-Object-td31120998.html
Re: [JSON] Stable Child Resource Order
On 07.04.11 09:17, Felix Meschberger fmesc...@adobe.com wrote: the special array * would contain the names of the child resources in the order provided by the resource resolver. Maybe we could just use a regular illegal property name like :child-node-order or :sling:child-node-order instead of a single character. What about using :order? And the selector would be order as well (e.g. foo.order.infinity.json). Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
Hi, Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander Klimetschek: On 07.04.11 09:17, Felix Meschberger fmesc...@adobe.com wrote: the special array * would contain the names of the child resources in the order provided by the resource resolver. Maybe we could just use a regular illegal property name like :child-node-order or :sling:child-node-order instead of a single character. What about using :order? The problem is that :order already is used by the Sling POST Servlet to define the order of newly inserted nodes... While I don't think we are walking into a collision here in the near future, I would like to either not use that name or correlate an potential update of Sling POST Servlet's use of the parameter, e.g. to define/update the order of nodes And the selector would be order as well (e.g. foo.order.infinity.json). sounds reasonable to me. Regards Felix
Re: [JSON] Stable Child Resource Order
On 07.04.11 13:31, Felix Meschberger fmesc...@adobe.com wrote: The problem is that :order already is used by the Sling POST Servlet to define the order of newly inserted nodes... Ah, yes, I thought that one was named differently (should have checked :-)). But maybe this is ok? In all the cases I know, one never does a full round-trip, but rather uses some kind of form / dialog that defines the actual items to show and to update, so if :order is not part of it (or not sent along), there will be no conflict. But of course, I don't know what other Sling users are doing. While I don't think we are walking into a collision here in the near future, I would like to either not use that name or correlate an potential update of Sling POST Servlet's use of the parameter, e.g. to define/update the order of nodes If it is 100% round-trippable (i.e. adding support for :order as an array to the Sling POST servlet), why not? Inventing new names adds complexity and potential for confusion... Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
why not just render the ordered child nodes as a json array? On Apr 7, 2011 10:22 AM, Alexander Klimetschek aklim...@adobe.com wrote: On 07.04.11 13:31, Felix Meschberger fmesc...@adobe.com wrote: The problem is that :order already is used by the Sling POST Servlet to define the order of newly inserted nodes... Ah, yes, I thought that one was named differently (should have checked :-)). But maybe this is ok? In all the cases I know, one never does a full round-trip, but rather uses some kind of form / dialog that defines the actual items to show and to update, so if :order is not part of it (or not sent along), there will be no conflict. But of course, I don't know what other Sling users are doing. While I don't think we are walking into a collision here in the near future, I would like to either not use that name or correlate an potential update of Sling POST Servlet's use of the parameter, e.g. to define/update the order of nodes If it is 100% round-trippable (i.e. adding support for :order as an array to the Sling POST servlet), why not? Inventing new names adds complexity and potential for confusion... Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
On 07.04.11 19:38, Eric Norman eric.d.nor...@gmail.com wrote: why not just render the ordered child nodes as a json array? This would be much more incompatible with the existing way of using a JSON object, and then you need to think about what the name for the special property designated for the child node's names must be. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
On 07.04.11 20:46, Alexander Klimetschek aklim...@adobe.com wrote: On 07.04.11 19:38, Eric Norman eric.d.nor...@gmail.com wrote: why not just render the ordered child nodes as a json array? This would be much more incompatible with the existing way of using a JSON object, and then you need to think about what the name for the special property designated for the child node's names must be. ... and you can no longer quickly access the sub tree by name in javascript: root.child.grandchild.property = foo Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
thanks felix, i think we go the same way here - maybe it was not so clear from my wording :-) all i'm saying is: sling uses a JSON like format to present a resource tree which can cause problems for JSON/ECMA compliant clients that don't implement stable child object ordering. as mentioned by [3] this is very unfortunate that ECMA script engines don't do that. such clients currently can't re-use the existing JSON-Object decoder and need to implement it themselves. Maybe we could just use a regular illegal property name like :child-node-order or :sling:child-node-order instead of a single character sling is all about resources - not nodes, right :-) so i'd rather go for: :child-resource-names or a shorter :child-names regards, toby [3] http://old.nabble.com/iteration-order-for-Object-td31120998.html On Thu, Apr 7, 2011 at 4:31 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander Klimetschek: On 07.04.11 09:17, Felix Meschberger fmesc...@adobe.com wrote: the special array * would contain the names of the child resources in the order provided by the resource resolver. Maybe we could just use a regular illegal property name like :child-node-order or :sling:child-node-order instead of a single character. What about using :order? The problem is that :order already is used by the Sling POST Servlet to define the order of newly inserted nodes... While I don't think we are walking into a collision here in the near future, I would like to either not use that name or correlate an potential update of Sling POST Servlet's use of the parameter, e.g. to define/update the order of nodes And the selector would be order as well (e.g. foo.order.infinity.json). sounds reasonable to me. Regards Felix
Re: [JSON] Stable Child Resource Order
On Thu, Apr 7, 2011 at 10:38 AM, Eric Norman eric.d.nor...@gmail.com wrote:
why not just render the ordered child nodes as a json array?
that's another way, yes. but then you need to transport the resource
name in a special property. eg:
{
name: foo,
properties: {
},
children: [
{
name:child1,
properties: { ... },
children : [ ...]
},
{
...
}
]
but this would not be backward compatible and is more complex, too.
regards, toby
Re: [JSON] Stable Child Resource Order
Yes, but if order is important it seems more correct to send an array. And
adding a psuedo 'order' property isn't backward compatible either.
On Thu, Apr 7, 2011 at 11:26 AM, Tobias Bocanegra tri...@adobe.com wrote:
On Thu, Apr 7, 2011 at 10:38 AM, Eric Norman eric.d.nor...@gmail.com
wrote:
why not just render the ordered child nodes as a json array?
that's another way, yes. but then you need to transport the resource
name in a special property. eg:
{
name: foo,
properties: {
},
children: [
{
name:child1,
properties: { ... },
children : [ ...]
},
{
...
}
]
but this would not be backward compatible and is more complex, too.
regards, toby
Re: [JSON] Stable Child Resource Order
Is there any reason why you can't just make a custom script to output whatever JSON format you want? I'm not convinced this has usefulness outside your use case that would warrant changing the generic format. On Thu, Apr 7, 2011 at 10:26 AM, Tobias Bocanegra tri...@adobe.com wrote: thanks felix, i think we go the same way here - maybe it was not so clear from my wording :-) all i'm saying is: sling uses a JSON like format to present a resource tree which can cause problems for JSON/ECMA compliant clients that don't implement stable child object ordering. as mentioned by [3] this is very unfortunate that ECMA script engines don't do that. such clients currently can't re-use the existing JSON-Object decoder and need to implement it themselves. Maybe we could just use a regular illegal property name like :child-node-order or :sling:child-node-order instead of a single character sling is all about resources - not nodes, right :-) so i'd rather go for: :child-resource-names or a shorter :child-names regards, toby [3] http://old.nabble.com/iteration-order-for-Object-td31120998.html On Thu, Apr 7, 2011 at 4:31 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi, Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander Klimetschek: On 07.04.11 09:17, Felix Meschberger fmesc...@adobe.com wrote: the special array * would contain the names of the child resources in the order provided by the resource resolver. Maybe we could just use a regular illegal property name like :child-node-order or :sling:child-node-order instead of a single character. What about using :order? The problem is that :order already is used by the Sling POST Servlet to define the order of newly inserted nodes... While I don't think we are walking into a collision here in the near future, I would like to either not use that name or correlate an potential update of Sling POST Servlet's use of the parameter, e.g. to define/update the order of nodes And the selector would be order as well (e.g. foo.order.infinity.json). sounds reasonable to me. Regards Felix
Re: [JSON] Stable Child Resource Order
you can just add a feed.json.jsp file and use {resourcename}.feed.json
to render your custom output
HTH
Ruben
On 4/7/2011 12:47 PM, Eric Norman wrote:
Is there any reason why you can't just make a custom script to output
whatever JSON format you want? I'm not convinced this has usefulness
outside your use case that would warrant changing the generic format.
On Thu, Apr 7, 2011 at 10:26 AM, Tobias Bocanegratri...@adobe.com wrote:
thanks felix,
i think we go the same way here - maybe it was not so clear from my wording
:-)
all i'm saying is: sling uses a JSON like format to present a resource
tree which can cause problems for JSON/ECMA compliant clients that
don't implement stable child object ordering. as mentioned by [3] this
is very unfortunate that ECMA script engines don't do that.
such clients currently can't re-use the existing JSON-Object decoder
and need to implement it themselves.
Maybe we could just use a regular illegal property name like
:child-node-order or :sling:child-node-order instead of a single
character
sling is all about resources - not nodes, right :-) so i'd rather go for:
:child-resource-names or a shorter :child-names
regards, toby
[3] http://old.nabble.com/iteration-order-for-Object-td31120998.html
On Thu, Apr 7, 2011 at 4:31 AM, Felix Meschbergerfmesc...@adobe.com
wrote:
Hi,
Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander
Klimetschek:
On 07.04.11 09:17, Felix Meschbergerfmesc...@adobe.com wrote:
the special array * would contain the names of the child resources
in the order provided by the resource resolver.
Maybe we could just use a regular illegal property name like
:child-node-order or :sling:child-node-order instead of a single
character.
What about using :order?
The problem is that :order already is used by the Sling POST Servlet
to define the order of newly inserted nodes...
While I don't think we are walking into a collision here in the near
future, I would like to either not use that name or correlate an
potential update of Sling POST Servlet's use of the parameter, e.g. to
define/update the order of nodes
And the selector would be order as well (e.g.
foo.order.infinity.json).
sounds reasonable to me.
Regards
Felix
Re: [JSON] Stable Child Resource Order
On 07.04.11 21:47, Eric Norman eric.d.nor...@gmail.com wrote: Is there any reason why you can't just make a custom script to output whatever JSON format you want? I'm not convinced this has usefulness outside your use case that would warrant changing the generic format. That's what we are discussing: how to integrate it as simple as possible without breaking things ;-) Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [JSON] Stable Child Resource Order
hi,
the current default render servlet for JSON [0] uses the described
format. as there are already clients relying on this format, we can't
just change it. therefore adding an additional name array keeps the
format backward compatible and solves the problem.
regards, toby
[0]
http://svn.apache.org/viewvc/sling/trunk/bundles/servlets/get/src/main/java/org/apache/sling/servlets/get/impl/helpers/JsonRendererServlet.java?view=markup
On Thu, Apr 7, 2011 at 12:52 PM, Ruben Reusser r...@headwire.com wrote:
you can just add a feed.json.jsp file and use {resourcename}.feed.json
to render your custom output
HTH
Ruben
On 4/7/2011 12:47 PM, Eric Norman wrote:
Is there any reason why you can't just make a custom script to output
whatever JSON format you want? I'm not convinced this has usefulness
outside your use case that would warrant changing the generic format.
On Thu, Apr 7, 2011 at 10:26 AM, Tobias Bocanegratri...@adobe.com wrote:
thanks felix,
i think we go the same way here - maybe it was not so clear from my wording
:-)
all i'm saying is: sling uses a JSON like format to present a resource
tree which can cause problems for JSON/ECMA compliant clients that
don't implement stable child object ordering. as mentioned by [3] this
is very unfortunate that ECMA script engines don't do that.
such clients currently can't re-use the existing JSON-Object decoder
and need to implement it themselves.
Maybe we could just use a regular illegal property name like
:child-node-order or :sling:child-node-order instead of a single
character
sling is all about resources - not nodes, right :-) so i'd rather go for:
:child-resource-names or a shorter :child-names
regards, toby
[3] http://old.nabble.com/iteration-order-for-Object-td31120998.html
On Thu, Apr 7, 2011 at 4:31 AM, Felix Meschbergerfmesc...@adobe.com
wrote:
Hi,
Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander
Klimetschek:
On 07.04.11 09:17, Felix Meschbergerfmesc...@adobe.com wrote:
the special array * would contain the names of the child resources
in the order provided by the resource resolver.
Maybe we could just use a regular illegal property name like
:child-node-order or :sling:child-node-order instead of a single
character.
What about using :order?
The problem is that :order already is used by the Sling POST Servlet
to define the order of newly inserted nodes...
While I don't think we are walking into a collision here in the near
future, I would like to either not use that name or correlate an
potential update of Sling POST Servlet's use of the parameter, e.g. to
define/update the order of nodes
And the selector would be order as well (e.g.
foo.order.infinity.json).
sounds reasonable to me.
Regards
Felix
