Issue Details (XML | Word | Printable)

Key: CMIS-188
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Al Brown
Reporter: Ethan Gur-esh
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
OASIS Content Management Interoperability Services (CMIS) TC

Should it be optional to support "getDescendants" with an arbitrary "depth"?

Created: 14/May/09 06:58 PM   Updated: 11/Jan/10 07:22 PM
Component/s: Domain Model
Affects Version/s: None
Fix Version/s: Draft 0.62

Proposal:
1) Add a NEW method to the Navigation Service called "getFolderTree" -- This method will be functionally identical to calling getDescendants(depth=-1; type=Folder)
- Open question: We can choose to expose a "folderId" parameter, in which case it's really "getFolderSubtree", or we can say that there's no folder param and it always returns the folder tree starting at the root folder. (I prefer the latter approach but could go either way).
- Open question: Should this method ALSO be optional? (I'd prefer it it's required... but we should see if some repositories can't support this).

2) We will add a NEW repository-optional capability (in section 2.1.1) as follows:
- Name: capabilityDescendantNavigation
- Type: Boolean

If false, then the repository will throw the notSupported exception if the caller attempts to invoke the getDescendants method.

------------

In the ATOMPub binding, the services doc should be updated to expose this capability (as a link).


 Description  « Hide
The current definition of the "getDescendants" method can take in 3 values for the "depth" parameter:
* 1: Which behaves like GetChildren
* -1: Which gets ALL descendants, regardless of depth
* [2..n]: Which gets ONLY decendants up to the depth level specified.

But I'm not sure that many repositories can handle the [2..n] case very efficiently. (E.g. in SharePoint the native data tables make this query non-trivial to execute, even though the "-1" and "1" cases are very efficient.)

Should we provide a way for repositories to say that they don't support getting an arbitrary depth of children? Or maybe just remove that case, by saying that getChilren is ALWAYS with a depth of "-1" (i.e. remove the parameter entirely?)

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Al Brown added a comment - 04/Jun/09 07:09 PM
defaulting to -1 is bad design. I would suggest the service states the default depth is repository specific and SHOULD at least be two.

Al Brown added a comment - 15/Jun/09 01:29 PM
deferred - need proposal

Al Brown added a comment - 22/Jun/09 12:42 PM
Ethan to send a proposal around before next call

Florian Müller added a comment - 30/Jun/09 04:17 AM
A repository should be allowed to cut the response of getFolderTree at a certain level. This should be indicated somehow.
Returning the whole folder tree of a big repository (50,000+ folders) would be a waste of resources, time and bandwidth since most clients wouldn't be able to make use of it.

Florent Guillaume added a comment - 01/Jul/09 05:36 AM
Florian, I agree, but when earlier (CMIS-42) I proposed adding batching controls to getDescendants (AtomPub has them natively but SOAP would need it) it wasn't felt that this was necessary...

Ethan Gur-esh added a comment - 01/Jul/09 08:04 PM
Updated as per proposal

Ethan Gur-esh added a comment - 02/Jul/09 01:07 PM
Al -- I've updated the domain model. Please update the bindings accordingly.

Al Brown added a comment - 05/Jan/10 12:15 AM
JIRA Cleanup