masarati@aero.polimi.it wrote:
quanah@zimbra.com wrote:
Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108)
It would be extremely useful to have an extended operation that allows querying the number of children of a given (sub)tree, so that one can avoid iterating through the entire subtree to determine this number.
Might as well ask for the numSubordinates operational attribute to be implemented instead, this doesn't seem to merit a new exop. And for numSubordinates, see the -devel archives for why we chose not to implement it.
In either case, the server still needs to iterate over all entries internally, and the result has to take ACLs and entry disclosure into account.
An exop would allow to easily discriminate between intentional and "catchall" requests, like "+". Moreover, it might make sense to discriminate at least between subtree and onelevel number of subordinates; this would require two distinct operational attributes, or a parameter in the exop.
I'm not endorsing either solution, I'm just pointing out possible pros and cons.
If you want to be able to distinguish results based on scope then it makes more sense to just define a Search control. Like No-op - count the entries that would be returned, instead of returning them. (And bypassing the sizelimit too, but probably not bypassing timelimit.)
I'm drafting the code to implement this no-op search.
The semantics consists in a control request in a search request that results in returning no intermediate responses, only a final response with a control response that contains summary information on what the search would have done.
The request control value is empty.
The response control value contains: - the error that the search would have returned if it were performed regularly (should differ from the one actually returned only in case of sizelimit exceeded) - the number of entries that would be returned - the number of search references that would be returned
The search request should request no attributes (in any case no attributes will be returned); I'm not sure whether it is preferable to simply ignore requested attrs or the control must require that no attrs ("1.1") be explicitly requested; I favor the first (ignore req attrs) to ease interoperability; similarly, attrsOnly can be safely ignored.
The rest of the search should be dealt with as usual (base, scope, filter, alias dereferencing and so on), as well as ACL. This allows, for example, to count immediate children (scope=onelevel), to count subtrees (scope=subtree); the filter allows to select what is counted; and so on.
The code is almost done; am I missing anything? In case, let me know so I can fix it before committing.
Thanks, p.