Re: (ITS#6598) EXOP to return number of children of a (sub)tree

[masarati@aero.polimi.it]

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