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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > > > > > > > > > > > -- -----------------------------------------< [EMAIL PROTECTED] >--- 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 >---
