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 <[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
> > > > >
> > > > >
> > >
> > >
> >
> 
> 

Reply via email to