Full_Name: Michael Str�der Version: OS: URL: Submission from: (NULL) (83.124.19.230) Would be nice if slapd or a suitable backend like back-bdb or back-hdb would maintain operational attributes for entries containing the number of direct and all subordinate entries. These operational attributes should be called numSubordinates and numAllSubordinates like on some other LDAP server products and use the Integer syntax.
michael@stroeder.com wrote: > Would be nice if slapd or a suitable backend like back-bdb or back-hdb would > maintain operational attributes for entries containing the number of direct and > all subordinate entries. > > These operational attributes should be called numSubordinates and > numAllSubordinates like on some other LDAP server products and use the Integer > syntax. Currently back-hdb already maintains a count of immediate children, back-bdb does not. Neither maintains a count of all children. That might be expensive to generate, haven't thought about it much. 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 maintain. -- -- 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/
Howard Chu wrote: > > Currently back-hdb already maintains a count of immediate children, Would be handy for some sync processes to know in advance how many entries to expect when doing an exhaustive search in a container. > 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 > maintain. 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. Ciao, Michael.
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 >> maintain. >> > > 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/
Howard Chu wrote: > 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. draft-boreham-numsubordinates-01.txt says: [..] Every entry in the DIT MAY have a numSubordinates operational attribute the contents of which indicate how many immediate subordinates that entry has. [..] Don't have a more recent copy of the draft. Ciao, Michael.
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. Kurt At 06:00 AM 11/8/2005, hyc@symas.com 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 >>> maintain. >>> >> >> 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/
changed state Open to Suspended
changed notes changed state Suspended to Closed
moved from Incoming to Archive.Incoming
rejected