[Date Prev][Date Next]
Re: (ITS#4161) Op. attrs. numSubordinates / numAllSubordinates
I can see how it would be useful for a client to determine
how many objects would be returned by some search operation
without actually requiring the objects to be returned.
The problem with these attributes is they don't address the
general problem. That is, they are only useful in limited
is special cases.
Hence, I rather skip this extension.
At 06:00 AM 11/8/2005, firstname.lastname@example.org wrote:
>Michael Ströder wrote:
>>> I'm inclined to reject this request since it can reveal the presence of
>>> entries that otherwise would not be disclosed (due to ACLs), and the
>>> work required to conform to ACLs would make it fairly expensive to
>> How about just leaving this up to the access control rules defined by
>> the administrator for these particular attributes? That's how other
>> products handle this. Same like hasSubordinates.
>That's fair. The other issue which I recall was raised the last time
>this suggestion was made, (and the reason we decided to only implement
>the hasSubordinates attribute) is that there was neither a formal
>specification nor an ad hoc standard defining the semantics of the
>numSubordinates attribute. Some vendors treated it only as the one-level
>count, while others treated it as the subtree count. I haven't looked,
>but if you can show that the distinction between numSubordinates and
>numAllSubordinates is well-defined and well-supported, that would make
>the argument more convincing.
> -- Howard Chu
> Chief Architect, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc
> OpenLDAP Core Team http://www.openldap.org/project/