You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Philipp Koch <ph...@day.com> on 2008/01/09 10:42:02 UTC
json export: recursive by default
hi,
currently the DefaultServlet handles the json content "export". it
exports only the current node and its properties. i am not sure if
this default behaviour is desirable and would expect that the default
behaviour would be so that the json exporter would recursively export
the current node and its descendants.
my proposal:
full recursive mode should be default. if you would like to specify
the recursion depth one could e.g. specify a request parameter that
specifies the depth.
what dou others think?
regards,
philipp
Re: json export: recursive by default
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 10, 2008 9:46 AM, Tobias Bocanegra <to...@day.com> wrote:
> ...so i suggest to have:
>
> /mynode.0.json -> returns the node and its properties
> /mynode.1.json -> returns the node, it properties and the child nodes
> and their properties
> ...
> /mynode.infinity.json -> returns the entire subtree.
>
> and i suggest to treat the '0' case as default.
Which (just to be very clear ;-) means that /mynode.json works as /mynode.0.json
+1 to your proposal, then (we could bikeshed about this for ages, and
yours is a reasonable proposal).
-Bertrand
Re: json export: recursive by default
Posted by pi...@wasabicowboy.com.
+1
Sent via BlackBerry from T-Mobile
-----Original Message-----
From: Felix Meschberger <fm...@gmail.com>
Date: Thu, 10 Jan 2008 09:52:33
To:sling-dev@incubator.apache.org
Subject: Re: json export: recursive by default
+1
Regards
Felix
Am Donnerstag, den 10.01.2008, 09:46 +0100 schrieb Tobias Bocanegra:
> > #1 - i want all the properties of a node in one response
> > #2 - i want all the childnodes of a node and their properties in one response
> > #3 - i want all the childnodes and properties at an infinite or
> > arbitrary level in
> > one response
> >
> > i would argue that #1 & #2 make up 90% of all the requests.
> > #1 & #2 are not a big deal with respect to serverside caching since
> > they are usually very cheap.
> > so i would argue that with respect to caching we should probably take
> > care of the expensive #3...
> >
> > personally, with ujax in mind, i certainly would argue that the default
> > behavior is important for a method like ujax.getContent("/mynode")
> > should be to just get the proprties of a node in a shallow manner.
> > which to me hints that this should probably also be the the default
> > behaviour of "/mynode.json" (== "/mynode.0.json").
> > to align with the webdav propfind "Depth" header i would recommend to go with
> > "/mynode.infinity.json"
>
> you probably right. the 0.5 case might not be relevant. since even for
> browsing, you may need to node type of a child node. e.g. for drawing
> the correct icon. so i suggest to have:
>
> /mynode.0.json -> returns the node and its properties
> /mynode.1.json -> returns the node, it properties and the child nodes
> and their properties
> ...
> /mynode.infinity.json -> returns the entire subtree.
>
> and i suggest to treat the '0' case as default.
>
> regards, toby
Re: json export: recursive by default
Posted by Felix Meschberger <fm...@gmail.com>.
+1
Regards
Felix
Am Donnerstag, den 10.01.2008, 09:46 +0100 schrieb Tobias Bocanegra:
> > #1 - i want all the properties of a node in one response
> > #2 - i want all the childnodes of a node and their properties in one response
> > #3 - i want all the childnodes and properties at an infinite or
> > arbitrary level in
> > one response
> >
> > i would argue that #1 & #2 make up 90% of all the requests.
> > #1 & #2 are not a big deal with respect to serverside caching since
> > they are usually very cheap.
> > so i would argue that with respect to caching we should probably take
> > care of the expensive #3...
> >
> > personally, with ujax in mind, i certainly would argue that the default
> > behavior is important for a method like ujax.getContent("/mynode")
> > should be to just get the proprties of a node in a shallow manner.
> > which to me hints that this should probably also be the the default
> > behaviour of "/mynode.json" (== "/mynode.0.json").
> > to align with the webdav propfind "Depth" header i would recommend to go with
> > "/mynode.infinity.json"
>
> you probably right. the 0.5 case might not be relevant. since even for
> browsing, you may need to node type of a child node. e.g. for drawing
> the correct icon. so i suggest to have:
>
> /mynode.0.json -> returns the node and its properties
> /mynode.1.json -> returns the node, it properties and the child nodes
> and their properties
> ...
> /mynode.infinity.json -> returns the entire subtree.
>
> and i suggest to treat the '0' case as default.
>
> regards, toby
Re: json export: recursive by default
Posted by Philipp Koch <ph...@day.com>.
> /mynode.0.json -> returns the node and its properties
> /mynode.1.json -> returns the node, it properties and the child nodes
> and their properties
> ...
> /mynode.infinity.json -> returns the entire subtree.
>
> and i suggest to treat the '0' case as default.
finally convinced ;-). this all makes sense.
regards,
philipp
On 1/10/08, Tobias Bocanegra <to...@day.com> wrote:
> > #1 - i want all the properties of a node in one response
> > #2 - i want all the childnodes of a node and their properties in one response
> > #3 - i want all the childnodes and properties at an infinite or
> > arbitrary level in
> > one response
> >
> > i would argue that #1 & #2 make up 90% of all the requests.
> > #1 & #2 are not a big deal with respect to serverside caching since
> > they are usually very cheap.
> > so i would argue that with respect to caching we should probably take
> > care of the expensive #3...
> >
> > personally, with ujax in mind, i certainly would argue that the default
> > behavior is important for a method like ujax.getContent("/mynode")
> > should be to just get the proprties of a node in a shallow manner.
> > which to me hints that this should probably also be the the default
> > behaviour of "/mynode.json" (== "/mynode.0.json").
> > to align with the webdav propfind "Depth" header i would recommend to go with
> > "/mynode.infinity.json"
>
> you probably right. the 0.5 case might not be relevant. since even for
> browsing, you may need to node type of a child node. e.g. for drawing
> the correct icon. so i suggest to have:
>
> /mynode.0.json -> returns the node and its properties
> /mynode.1.json -> returns the node, it properties and the child nodes
> and their properties
> ...
> /mynode.infinity.json -> returns the entire subtree.
>
> and i suggest to treat the '0' case as default.
>
> regards, toby
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>
Re: json export: recursive by default
Posted by Tobias Bocanegra <to...@day.com>.
> #1 - i want all the properties of a node in one response
> #2 - i want all the childnodes of a node and their properties in one response
> #3 - i want all the childnodes and properties at an infinite or
> arbitrary level in
> one response
>
> i would argue that #1 & #2 make up 90% of all the requests.
> #1 & #2 are not a big deal with respect to serverside caching since
> they are usually very cheap.
> so i would argue that with respect to caching we should probably take
> care of the expensive #3...
>
> personally, with ujax in mind, i certainly would argue that the default
> behavior is important for a method like ujax.getContent("/mynode")
> should be to just get the proprties of a node in a shallow manner.
> which to me hints that this should probably also be the the default
> behaviour of "/mynode.json" (== "/mynode.0.json").
> to align with the webdav propfind "Depth" header i would recommend to go with
> "/mynode.infinity.json"
you probably right. the 0.5 case might not be relevant. since even for
browsing, you may need to node type of a child node. e.g. for drawing
the correct icon. so i suggest to have:
/mynode.0.json -> returns the node and its properties
/mynode.1.json -> returns the node, it properties and the child nodes
and their properties
...
/mynode.infinity.json -> returns the entire subtree.
and i suggest to treat the '0' case as default.
regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: json export: recursive by default
Posted by David Nuescheler <da...@day.com>.
hi guys,
in my experience there are really 3 cases that are worth
distinguishing from a users perspective.
#1 - i want all the properties of a node in one response
#2 - i want all the childnodes of a node and their properties in one response
#3 - i want all the childnodes and properties at an infinite or
arbitrary level in
one response
i would argue that #1 & #2 make up 90% of all the requests.
#1 & #2 are not a big deal with respect to serverside caching since
they are usually very cheap.
so i would argue that with respect to caching we should probably take
care of the expensive #3...
personally, with ujax in mind, i certainly would argue that the default
behavior is important for a method like ujax.getContent("/mynode")
should be to just get the proprties of a node in a shallow manner.
which to me hints that this should probably also be the the default
behaviour of "/mynode.json" (== "/mynode.0.json").
to align with the webdav propfind "Depth" header i would recommend to go with
"/mynode.infinity.json"
regards,
david
On 1/9/08, Tobias Bocanegra <to...@day.com> wrote:
> > > > Why not:
> > > >
> > > > /stuff.json?depth=1
> > > >
> > > > It's not like we need to use the URI mapping for everything.
> > > because this breaks caching.
> >
> > Really? I'm probably out of touch with current practice in HTTP
> > caching, but at least in theory there should be nothing in query
> > parameters that would prevent caching.
>
> but in real life. for example when a form input is used to display
> search results. so the content of the resulting page changes if the
> underlying search space changes. and since not all apps use proper
> cache prevention (like no-cache headers etc.) most proxies do not
> cache requests with a query (at least afaik).
>
> in any case, i find it a very good and simple differentiator (beside
> the common http headers) to decide whether to cache responses or not.
> and i would keep it this way in sling.
>
> regards, toby
> --
> -----------------------------------------< tobias.bocanegra@day.com >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com >---
>
Re: json export: recursive by default
Posted by Tobias Bocanegra <to...@day.com>.
> > > Why not:
> > >
> > > /stuff.json?depth=1
> > >
> > > It's not like we need to use the URI mapping for everything.
> > because this breaks caching.
>
> Really? I'm probably out of touch with current practice in HTTP
> caching, but at least in theory there should be nothing in query
> parameters that would prevent caching.
but in real life. for example when a form input is used to display
search results. so the content of the resulting page changes if the
underlying search space changes. and since not all apps use proper
cache prevention (like no-cache headers etc.) most proxies do not
cache requests with a query (at least afaik).
in any case, i find it a very good and simple differentiator (beside
the common http headers) to decide whether to cache responses or not.
and i would keep it this way in sling.
regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: json export: recursive by default
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 9, 2008 11:01 PM, Tobias Bocanegra <to...@day.com> wrote:
> > Why not:
> >
> > /stuff.json?depth=1
> >
> > It's not like we need to use the URI mapping for everything.
> because this breaks caching.
Really? I'm probably out of touch with current practice in HTTP
caching, but at least in theory there should be nothing in query
parameters that would prevent caching.
BR,
Jukka Zitting
Re: json export: recursive by default
Posted by Felix Meschberger <fm...@gmail.com>.
Am Mittwoch, den 09.01.2008, 22:01 +0100 schrieb Tobias Bocanegra:
> > Why not:
> >
> > /stuff.json?depth=1
> >
> > It's not like we need to use the URI mapping for everything.
> because this breaks caching.
>
> however, i think there are actually 2 use cases. the first is that you
> need the deep serialization of a tree, e.g. a page, or an exploded
> xml, or a dialog node structure description.... in this case you
> always want a depth=infinity. the other one is the 'browsing' use case
> where you only need the node and it's properties (and the names of the
> childnodes!). so this is a special case anyways. this would be like
> depth=0.5 :-)
This is an interesting proposal. Just a quick question, though: How
would you represent "child node names" here to distinguish them from
properties ? As empty objects ?
Regards
Felix
Re: json export: recursive by default
Posted by Padraic Hannon <pi...@wasabicowboy.com>.
I think the use case approach is the best way to unpack this. As such
it seems we have been discussing three use cases:
1 Display a node and its properties
2 Display a node, its properties, and its children
3 Display a node its properties, and the full structure underneath it
If those are the use cases then I think the first one is the most
basic case and should be the default, the other two should require
some sort of addition to the URI. On the other hand, I guess, the
discussion boils down to how we perceive the json request. Are we
asking to serialize an object graph? If so then we should dump the
whole thing. I am not sure, however, if I am comfortable with that
given the potential consequences of dumping tons of data.
Going back the the filesystem analogy given this structure:
/
/foo
/foo/child1
/bar
/bar/child2
When I ask to list / I do not get a recursive listing unless I
explicitly ask for it. Using the use cases above how would we expect
request calls to work? What should the URIs look like? I think I agree
with Toby that UC1 and UC2 should be collapsed so that a request for /
foo would return foo's attributes plus list foo's child node names. A
request for /foo.recurse would return /foo + all its children their
properties their children, and so on... With those two types of
request one could fulfill the browsing and the dump models Toby
described. I also agree that these should be done with selectors and
not query params as it makes caching much easier.
-paddy
On Jan 9, 2008, at 1:01 PM, Tobias Bocanegra wrote:
>> Why not:
>>
>> /stuff.json?depth=1
>>
>> It's not like we need to use the URI mapping for everything.
> because this breaks caching.
>
> however, i think there are actually 2 use cases. the first is that you
> need the deep serialization of a tree, e.g. a page, or an exploded
> xml, or a dialog node structure description.... in this case you
> always want a depth=infinity. the other one is the 'browsing' use case
> where you only need the node and it's properties (and the names of the
> childnodes!). so this is a special case anyways. this would be like
> depth=0.5 :-)
>
> so is there really a use case for depth=0 (i.e. node+properties) ?
> or is depth=0 just the node name, depth=1 the node name and it's
> properties and it's childnode names? etc. ?
>
> regards, toby
> --
> -----------------------------------------< tobias.bocanegra@day.com
> >---
> Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001
> Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com
> >---
Re: json export: recursive by default
Posted by Tobias Bocanegra <to...@day.com>.
> Why not:
>
> /stuff.json?depth=1
>
> It's not like we need to use the URI mapping for everything.
because this breaks caching.
however, i think there are actually 2 use cases. the first is that you
need the deep serialization of a tree, e.g. a page, or an exploded
xml, or a dialog node structure description.... in this case you
always want a depth=infinity. the other one is the 'browsing' use case
where you only need the node and it's properties (and the names of the
childnodes!). so this is a special case anyways. this would be like
depth=0.5 :-)
so is there really a use case for depth=0 (i.e. node+properties) ?
or is depth=0 just the node name, depth=1 the node name and it's
properties and it's childnode names? etc. ?
regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: json export: recursive by default
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 9, 2008 5:40 PM, Bertrand Delacretaz <bd...@apache.org> wrote:
> /stuff.json -> full recursion
> /stuff.1.json -> 1 level recursion
> etc...
Why not:
/stuff.json?depth=1
It's not like we need to use the URI mapping for everything.
BR,
Jukka Zitting
Re: json export: recursive by default
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 9, 2008 4:24 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I still prefer that full recursion is the default....
I would agree with that if that's the majority opinion, and if there's
a clear way of having less recursion.
So I'd be ok with
/stuff.json -> full recursion
/stuff.1.json -> 1 level recursion
etc...
-Bertrand
Re: json export: recursive by default
Posted by Philipp Koch <ph...@day.com>.
i completely agree with carsten (as i have already written in an earlier post).
regards,
philipp
On 1/9/08, Carsten Ziegeler <cz...@apache.org> wrote:
> Felix Meschberger wrote:
> > The problem with defaulting to full recursive export (which is what you
> > propose by omitting the selector), is that you may start a full
> > repositoy traversal by coincidence. Defaulting to just the properties of
> > the node prevents this.
> >
> > If we require some selector value to have a recursive traversal, we
> > enforce at least some thought on building the query.
> >
>
> I'm not 100% buying this argument, but I understand your concerns. I have to
> think how to build my url anyway: I have to find the right path, the
> right extension etc. So I know what I want to do. And we're talking
> about json here, so people who want to have a json representation should
> be able to think :)
>
> And usually once people find out that there is some magic "all" stuff,
> they will always invoke it anyway as soon as things go wrong :)
>
> In the end I think it doesn't really matter as long as we define this
> consistently - though I still prefer that full recursion is the default.
>
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
Re: json export: recursive by default
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> The problem with defaulting to full recursive export (which is what you
> propose by omitting the selector), is that you may start a full
> repositoy traversal by coincidence. Defaulting to just the properties of
> the node prevents this.
>
> If we require some selector value to have a recursive traversal, we
> enforce at least some thought on building the query.
>
I'm not 100% buying this argument, but I understand your concerns. I have to
think how to build my url anyway: I have to find the right path, the
right extension etc. So I know what I want to do. And we're talking
about json here, so people who want to have a json representation should
be able to think :)
And usually once people find out that there is some magic "all" stuff,
they will always invoke it anyway as soon as things go wrong :)
In the end I think it doesn't really matter as long as we define this
consistently - though I still prefer that full recursion is the default.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: json export: recursive by default
Posted by Felix Meschberger <fm...@gmail.com>.
The problem with defaulting to full recursive export (which is what you
propose by omitting the selector), is that you may start a full
repositoy traversal by coincidence. Defaulting to just the properties of
the node prevents this.
If we require some selector value to have a recursive traversal, we
enforce at least some thought on building the query.
Regards
Felix
Am Mittwoch, den 09.01.2008, 16:06 +0100 schrieb Tobias Bocanegra:
> what about omitting the depth selector for a full recursive export?
>
> eg:
> /a/b/c.json -> export all recursively
> /a/b/c.0.json -> export the 'c' node + props only
> /a/b/c.1.json -> export the 'c' node and all direct children
>
> regards, toby
>
> On 1/9/08, Philipp Koch <ph...@day.com> wrote:
> > > So you have an url "/a/b/c.-1.json" ? Not sure, whether is nice :-)
> > i do not want to win a beauty contest ;-) and if "all" is even nicer
> > is questionable (depends on personal bias) .
> >
> > regards, philipp
> >
> > On 1/9/08, Felix Meschberger <fm...@gmail.com> wrote:
> > > So you have an url "/a/b/c.-1.json" ? Not sure, whether is nice :-)
> > >
> > > Regards
> > > Felix
> > >
> > > Am Mittwoch, den 09.01.2008, 15:45 +0100 schrieb Philipp Koch:
> > > > >...requesting /a/b/c.all.json would return the subtree rooted at
> > > > > node c to be dumped as JSON.
> > > > what about using 0 or -1 instead of all. this would save some lines of
> > > > parsing and would from my point of view cleaner in terms of "depth
> > > > notation".
> > > >
> > > > regards,
> > > > philipp
> > > >
> > > > On 1/9/08, Felix Meschberger <fm...@gmail.com> wrote:
> > > > > Hi,
> > > > >
> > > > > Am Mittwoch, den 09.01.2008, 11:03 +0100 schrieb Carsten Ziegeler:
> > > > > > Bertrand Delacretaz wrote:
> > > > > > > On Jan 9, 2008 10:42 AM, Philipp Koch <ph...@day.com> wrote:
> > > > > > >
> > > > > > >> ...my proposal:
> > > > > > >> full recursive mode should be default. if you would like to specify
> > > > > > >> the recursion depth one could e.g. specify a request parameter that
> > > > > > >> specifies the depth....
> > > > > > >
> > > > > > > Isn't that a bit dangerous?
> > > > > > > A json GET at / would then get the whole repository...
> > > > > > >
> > > > > > Let's keep security issues etc. aside for a moment. I think the
> > > > > > important question is what do you expect if you invoke
> > > > > > /something/object.json?
> > > > > >
> > > > > > Just the first level? The whole object?
> > > > >
> > > > > It depends, how you define "the whole object". When accessing a node
> > > > > resource, the object is the node and thus returning the properties of
> > > > > the node is probably the whole object :-)
> > > > >
> > > > > After discussing this internally, the "correct" solution would probably
> > > > > be to default to just one level and allow to specify the number of
> > > > > levels to dump as a selector. This would also allow caching the result
> > > > > (as opposed to using a request parameter).
> > > > >
> > > > > So a request to /a/b/c.json would return the properties of node c as
> > > > > JSON and requesting /a/b/c.all.json would return the subtree rooted at
> > > > > node c to be dumped as JSON.
> > > > >
> > > > > > PS: Whatever the outcome of this discussion is, we should apply the same
> > > > > > rules to the XML output.
> > > > >
> > > > > Definitely.
> > > > >
> > > > > Regards
> > > > > Felix
> > > > >
> > > > >
> > >
> > >
> >
>
>
Re: json export: recursive by default
Posted by Tobias Bocanegra <to...@day.com>.
what about omitting the depth selector for a full recursive export?
eg:
/a/b/c.json -> export all recursively
/a/b/c.0.json -> export the 'c' node + props only
/a/b/c.1.json -> export the 'c' node and all direct children
regards, toby
On 1/9/08, Philipp Koch <ph...@day.com> wrote:
> > So you have an url "/a/b/c.-1.json" ? Not sure, whether is nice :-)
> i do not want to win a beauty contest ;-) and if "all" is even nicer
> is questionable (depends on personal bias) .
>
> regards, philipp
>
> On 1/9/08, Felix Meschberger <fm...@gmail.com> wrote:
> > So you have an url "/a/b/c.-1.json" ? Not sure, whether is nice :-)
> >
> > Regards
> > Felix
> >
> > Am Mittwoch, den 09.01.2008, 15:45 +0100 schrieb Philipp Koch:
> > > >...requesting /a/b/c.all.json would return the subtree rooted at
> > > > node c to be dumped as JSON.
> > > what about using 0 or -1 instead of all. this would save some lines of
> > > parsing and would from my point of view cleaner in terms of "depth
> > > notation".
> > >
> > > regards,
> > > philipp
> > >
> > > On 1/9/08, Felix Meschberger <fm...@gmail.com> wrote:
> > > > Hi,
> > > >
> > > > Am Mittwoch, den 09.01.2008, 11:03 +0100 schrieb Carsten Ziegeler:
> > > > > Bertrand Delacretaz wrote:
> > > > > > On Jan 9, 2008 10:42 AM, Philipp Koch <ph...@day.com> wrote:
> > > > > >
> > > > > >> ...my proposal:
> > > > > >> full recursive mode should be default. if you would like to specify
> > > > > >> the recursion depth one could e.g. specify a request parameter that
> > > > > >> specifies the depth....
> > > > > >
> > > > > > Isn't that a bit dangerous?
> > > > > > A json GET at / would then get the whole repository...
> > > > > >
> > > > > Let's keep security issues etc. aside for a moment. I think the
> > > > > important question is what do you expect if you invoke
> > > > > /something/object.json?
> > > > >
> > > > > Just the first level? The whole object?
> > > >
> > > > It depends, how you define "the whole object". When accessing a node
> > > > resource, the object is the node and thus returning the properties of
> > > > the node is probably the whole object :-)
> > > >
> > > > After discussing this internally, the "correct" solution would probably
> > > > be to default to just one level and allow to specify the number of
> > > > levels to dump as a selector. This would also allow caching the result
> > > > (as opposed to using a request parameter).
> > > >
> > > > So a request to /a/b/c.json would return the properties of node c as
> > > > JSON and requesting /a/b/c.all.json would return the subtree rooted at
> > > > node c to be dumped as JSON.
> > > >
> > > > > PS: Whatever the outcome of this discussion is, we should apply the same
> > > > > rules to the XML output.
> > > >
> > > > Definitely.
> > > >
> > > > Regards
> > > > Felix
> > > >
> > > >
> >
> >
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: json export: recursive by default
Posted by Philipp Koch <ph...@day.com>.
> So you have an url "/a/b/c.-1.json" ? Not sure, whether is nice :-)
i do not want to win a beauty contest ;-) and if "all" is even nicer
is questionable (depends on personal bias) .
regards, philipp
On 1/9/08, Felix Meschberger <fm...@gmail.com> wrote:
> So you have an url "/a/b/c.-1.json" ? Not sure, whether is nice :-)
>
> Regards
> Felix
>
> Am Mittwoch, den 09.01.2008, 15:45 +0100 schrieb Philipp Koch:
> > >...requesting /a/b/c.all.json would return the subtree rooted at
> > > node c to be dumped as JSON.
> > what about using 0 or -1 instead of all. this would save some lines of
> > parsing and would from my point of view cleaner in terms of "depth
> > notation".
> >
> > regards,
> > philipp
> >
> > On 1/9/08, Felix Meschberger <fm...@gmail.com> wrote:
> > > Hi,
> > >
> > > Am Mittwoch, den 09.01.2008, 11:03 +0100 schrieb Carsten Ziegeler:
> > > > Bertrand Delacretaz wrote:
> > > > > On Jan 9, 2008 10:42 AM, Philipp Koch <ph...@day.com> wrote:
> > > > >
> > > > >> ...my proposal:
> > > > >> full recursive mode should be default. if you would like to specify
> > > > >> the recursion depth one could e.g. specify a request parameter that
> > > > >> specifies the depth....
> > > > >
> > > > > Isn't that a bit dangerous?
> > > > > A json GET at / would then get the whole repository...
> > > > >
> > > > Let's keep security issues etc. aside for a moment. I think the
> > > > important question is what do you expect if you invoke
> > > > /something/object.json?
> > > >
> > > > Just the first level? The whole object?
> > >
> > > It depends, how you define "the whole object". When accessing a node
> > > resource, the object is the node and thus returning the properties of
> > > the node is probably the whole object :-)
> > >
> > > After discussing this internally, the "correct" solution would probably
> > > be to default to just one level and allow to specify the number of
> > > levels to dump as a selector. This would also allow caching the result
> > > (as opposed to using a request parameter).
> > >
> > > So a request to /a/b/c.json would return the properties of node c as
> > > JSON and requesting /a/b/c.all.json would return the subtree rooted at
> > > node c to be dumped as JSON.
> > >
> > > > PS: Whatever the outcome of this discussion is, we should apply the same
> > > > rules to the XML output.
> > >
> > > Definitely.
> > >
> > > Regards
> > > Felix
> > >
> > >
>
>
Re: json export: recursive by default
Posted by Felix Meschberger <fm...@gmail.com>.
So you have an url "/a/b/c.-1.json" ? Not sure, whether is nice :-)
Regards
Felix
Am Mittwoch, den 09.01.2008, 15:45 +0100 schrieb Philipp Koch:
> >...requesting /a/b/c.all.json would return the subtree rooted at
> > node c to be dumped as JSON.
> what about using 0 or -1 instead of all. this would save some lines of
> parsing and would from my point of view cleaner in terms of "depth
> notation".
>
> regards,
> philipp
>
> On 1/9/08, Felix Meschberger <fm...@gmail.com> wrote:
> > Hi,
> >
> > Am Mittwoch, den 09.01.2008, 11:03 +0100 schrieb Carsten Ziegeler:
> > > Bertrand Delacretaz wrote:
> > > > On Jan 9, 2008 10:42 AM, Philipp Koch <ph...@day.com> wrote:
> > > >
> > > >> ...my proposal:
> > > >> full recursive mode should be default. if you would like to specify
> > > >> the recursion depth one could e.g. specify a request parameter that
> > > >> specifies the depth....
> > > >
> > > > Isn't that a bit dangerous?
> > > > A json GET at / would then get the whole repository...
> > > >
> > > Let's keep security issues etc. aside for a moment. I think the
> > > important question is what do you expect if you invoke
> > > /something/object.json?
> > >
> > > Just the first level? The whole object?
> >
> > It depends, how you define "the whole object". When accessing a node
> > resource, the object is the node and thus returning the properties of
> > the node is probably the whole object :-)
> >
> > After discussing this internally, the "correct" solution would probably
> > be to default to just one level and allow to specify the number of
> > levels to dump as a selector. This would also allow caching the result
> > (as opposed to using a request parameter).
> >
> > So a request to /a/b/c.json would return the properties of node c as
> > JSON and requesting /a/b/c.all.json would return the subtree rooted at
> > node c to be dumped as JSON.
> >
> > > PS: Whatever the outcome of this discussion is, we should apply the same
> > > rules to the XML output.
> >
> > Definitely.
> >
> > Regards
> > Felix
> >
> >
Re: json export: recursive by default
Posted by Philipp Koch <ph...@day.com>.
>...requesting /a/b/c.all.json would return the subtree rooted at
> node c to be dumped as JSON.
what about using 0 or -1 instead of all. this would save some lines of
parsing and would from my point of view cleaner in terms of "depth
notation".
regards,
philipp
On 1/9/08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Am Mittwoch, den 09.01.2008, 11:03 +0100 schrieb Carsten Ziegeler:
> > Bertrand Delacretaz wrote:
> > > On Jan 9, 2008 10:42 AM, Philipp Koch <ph...@day.com> wrote:
> > >
> > >> ...my proposal:
> > >> full recursive mode should be default. if you would like to specify
> > >> the recursion depth one could e.g. specify a request parameter that
> > >> specifies the depth....
> > >
> > > Isn't that a bit dangerous?
> > > A json GET at / would then get the whole repository...
> > >
> > Let's keep security issues etc. aside for a moment. I think the
> > important question is what do you expect if you invoke
> > /something/object.json?
> >
> > Just the first level? The whole object?
>
> It depends, how you define "the whole object". When accessing a node
> resource, the object is the node and thus returning the properties of
> the node is probably the whole object :-)
>
> After discussing this internally, the "correct" solution would probably
> be to default to just one level and allow to specify the number of
> levels to dump as a selector. This would also allow caching the result
> (as opposed to using a request parameter).
>
> So a request to /a/b/c.json would return the properties of node c as
> JSON and requesting /a/b/c.all.json would return the subtree rooted at
> node c to be dumped as JSON.
>
> > PS: Whatever the outcome of this discussion is, we should apply the same
> > rules to the XML output.
>
> Definitely.
>
> Regards
> Felix
>
>
Re: json export: recursive by default
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 09.01.2008, 11:03 +0100 schrieb Carsten Ziegeler:
> Bertrand Delacretaz wrote:
> > On Jan 9, 2008 10:42 AM, Philipp Koch <ph...@day.com> wrote:
> >
> >> ...my proposal:
> >> full recursive mode should be default. if you would like to specify
> >> the recursion depth one could e.g. specify a request parameter that
> >> specifies the depth....
> >
> > Isn't that a bit dangerous?
> > A json GET at / would then get the whole repository...
> >
> Let's keep security issues etc. aside for a moment. I think the
> important question is what do you expect if you invoke
> /something/object.json?
>
> Just the first level? The whole object?
It depends, how you define "the whole object". When accessing a node
resource, the object is the node and thus returning the properties of
the node is probably the whole object :-)
After discussing this internally, the "correct" solution would probably
be to default to just one level and allow to specify the number of
levels to dump as a selector. This would also allow caching the result
(as opposed to using a request parameter).
So a request to /a/b/c.json would return the properties of node c as
JSON and requesting /a/b/c.all.json would return the subtree rooted at
node c to be dumped as JSON.
> PS: Whatever the outcome of this discussion is, we should apply the same
> rules to the XML output.
Definitely.
Regards
Felix
Re: json export: recursive by default
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> On Jan 9, 2008 10:42 AM, Philipp Koch <ph...@day.com> wrote:
>
>> ...my proposal:
>> full recursive mode should be default. if you would like to specify
>> the recursion depth one could e.g. specify a request parameter that
>> specifies the depth....
>
> Isn't that a bit dangerous?
> A json GET at / would then get the whole repository...
>
Let's keep security issues etc. aside for a moment. I think the
important question is what do you expect if you invoke
/something/object.json?
Just the first level? The whole object?
I personally would expect the whole object.
PS: Whatever the outcome of this discussion is, we should apply the same
rules to the XML output.
Carsten
> Not sure what to suggest - maybe a default recursion level of 1, like
> in interactive browsing scenarios?
>
> -Bertrand
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: json export: recursive by default
Posted by Philipp Koch <ph...@day.com>.
> Isn't that a bit dangerous?
> A json GET at / would then get the whole repository...
yes and no. you also cannot prevent somebody from specifying the
recursion depth of 1000 (or whatever) applied at /....
regards, philipp
On 1/9/08, Bertrand Delacretaz <bd...@apache.org> wrote:
> On Jan 9, 2008 10:42 AM, Philipp Koch <ph...@day.com> wrote:
>
> > ...my proposal:
> > full recursive mode should be default. if you would like to specify
> > the recursion depth one could e.g. specify a request parameter that
> > specifies the depth....
>
> Isn't that a bit dangerous?
> A json GET at / would then get the whole repository...
>
> Not sure what to suggest - maybe a default recursion level of 1, like
> in interactive browsing scenarios?
>
> -Bertrand
>
Re: json export: recursive by default
Posted by Alexander Klimetschek <ak...@day.com>.
+1 (with the non-committer hat in mind ;-)
I find the /foo.all.json and /foo.1.json notation very intuitive. And /
foo.json only returns the foo node and its properties.
Alex
Am 09.01.2008 um 16:58 schrieb pih@wasabicowboy.com:
> I like felix's idea of using selectors. I would hate to call /
> foo.json and get it and all its child nodes. Think of a file system,
> you don't expect to request the root folder and get a full dump.
> However, if you requested /foo.recurs.json you may expect a full dump.
>
> Paddy
> Sent via BlackBerry from T-Mobile
>
> -----Original Message-----
> From: "Bertrand Delacretaz" <bd...@apache.org>
>
> Date: Wed, 9 Jan 2008 16:41:20
> To:sling-dev@incubator.apache.org
> Subject: Re: json export: recursive by default
>
>
> On Jan 9, 2008 4:08 PM, Tobias Bocanegra <to...@day.com>
> wrote:
>>> Isn't that a bit dangerous?
>>> A json GET at / would then get the whole repository...
>> and how would you do that? is there a way addressing the root node ?
>>
>> GET /.json HTTP/1.1 ?
>
> Ok, not the root then, but GET /content.json will still dump the whole
> /content subtree if full recursion is the default.
>
> -Bertrand
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: json export: recursive by default
Posted by pi...@wasabicowboy.com.
I like felix's idea of using selectors. I would hate to call /foo.json and get it and all its child nodes. Think of a file system, you don't expect to request the root folder and get a full dump. However, if you requested /foo.recurs.json you may expect a full dump.
Paddy
Sent via BlackBerry from T-Mobile
-----Original Message-----
From: "Bertrand Delacretaz" <bd...@apache.org>
Date: Wed, 9 Jan 2008 16:41:20
To:sling-dev@incubator.apache.org
Subject: Re: json export: recursive by default
On Jan 9, 2008 4:08 PM, Tobias Bocanegra <to...@day.com> wrote:
> > Isn't that a bit dangerous?
> > A json GET at / would then get the whole repository...
> and how would you do that? is there a way addressing the root node ?
>
> GET /.json HTTP/1.1 ?
Ok, not the root then, but GET /content.json will still dump the whole
/content subtree if full recursion is the default.
-Bertrand
Re: json export: recursive by default
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 9, 2008 4:08 PM, Tobias Bocanegra <to...@day.com> wrote:
> > Isn't that a bit dangerous?
> > A json GET at / would then get the whole repository...
> and how would you do that? is there a way addressing the root node ?
>
> GET /.json HTTP/1.1 ?
Ok, not the root then, but GET /content.json will still dump the whole
/content subtree if full recursion is the default.
-Bertrand
Re: json export: recursive by default
Posted by Tobias Bocanegra <to...@day.com>.
> Isn't that a bit dangerous?
> A json GET at / would then get the whole repository...
and how would you do that? is there a way addressing the root node ?
GET /.json HTTP/1.1 ?
GET /jcr:root.json HTTP/1.1 ?
regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
Re: json export: recursive by default
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 9, 2008 10:42 AM, Philipp Koch <ph...@day.com> wrote:
> ...my proposal:
> full recursive mode should be default. if you would like to specify
> the recursion depth one could e.g. specify a request parameter that
> specifies the depth....
Isn't that a bit dangerous?
A json GET at / would then get the whole repository...
Not sure what to suggest - maybe a default recursion level of 1, like
in interactive browsing scenarios?
-Bertrand