Hmmm. Good point. I changed my mind (slightly) - the behavior Jeff is describing can be supported, but should be disabled by default.
Ian - to your question, with the default configuration, /x/y/z.(anything).json should not output 2M child nodes. IMHO, if you as a system operator decide to let clients request all 2M nodes, that should be your prerogative to do so via configuration. In reality, however, if you have that type of structure, I think you're more likely to do content discovery by search rather than browse. WDYT? Justin On Thu, Dec 1, 2011 at 5:53 PM, Ian Boston <i...@tfd.co.uk> wrote: > Hi, > Thinking about this some more, > Assuming the content system can support this for a moment. > /x/y/z has 2M direct child nodes, what does /x/y/z.-1.json respond > with? 2M links to those child nodes. > > Does the system need to support paging, in the same way atom does? > eg /x/y/z.-1.json?page=1 > > With Sling built on Jackrabbit this doesn't happen (yet), since > Jackrabbit (IIUC) stores child nodes internally as an array of > pointers on the parent node, so it may not be a real issue, but Sling > on something else may encounter this. In general the solution has been > to refuse to list child Resources via the Resource interface, and do > something custom with paging enforced, but as soon as paging is > introduced, order becomes relevant, and that opens up the validity of > ordering a map in json, which IIRC is defined as a bag not a list. > > Ian > > On 2 December 2011 08:50, Justin Edelson <jus...@justinedelson.com> wrote: >> Hi Jeff, >> I'm not sure why you can't just increase the limit if you run into >> this problem, but I am not opposed to making this change on principal. >> >> I'm very intrigued by the idea of a PostProcessor which limits the >> number of nodes at a particular point in the hierarchy, but that's not >> going to be 100% effective as Sling doesn't "own" the repository per >> se. >> >> Justin >> >> On Thu, Dec 1, 2011 at 4:26 PM, Jeff Young <j...@adobe.com> wrote: >>> The intent behind the limitation seems sound, but the implementation has >>> (to my mind) a slight flaw. >>> >>> A legitimate client which needs the information could presumably implement >>> its own traversal to descend the tree. But this only works if the json >>> servlet is always allowed to return at least a depth of 1. The current >>> implementation limits the depth to 0 if the node in question has more than >>> the limit number of children. >>> >>> I was discussing this with Alex, who pointed out that the intent was to be >>> defensive. However, if we really want to limit the *number of children* a >>> node can have, then we ought to do that elsewhere. Given that a node >>> *does* have a certain number of children, the json servlet needs to at >>> least support the enumeration of said children. >>> >>> So I'd like to propose that we amend the DOS-protection-algorithm to stop >>> at 1, rather than 0. >>> >>> Thoughts? >>> >>> Thanks, >>> Jeff. >>> >>> (PS: apologies if this gets sent out twice, but I think ezmlm ate the first >>> posting because I hadn't yet cofirmed my subscription so I'm re-sending.) >>> >>> >>> >>> Jeff Young | Principal Scientist | Adobe Distinguished Inventor >>> Adobe Systems Software Ireland Ltd. >>> Registered Office: 4-6 Riverwalk, Citywest Business Campus, >>> Saggart, Dublin 24, Ireland Company No. 344992 >>> P Please consider your environmental responsibility before printing this >>> e-mail. >>> >>> >>
