For someone which follows the discussion with distance, I find it quite confusing.
Netscape Directory Server, Sun Directory Server, Red Hat Directory Server, OpenDS, OpenDJ, OUD and most likely UnboundID directory are all providing the standard hasSubordinates, and the numSubordinates attribute. So I find it confusing that you are now talking about defining new attributes nbSubordinates, nbChildren… that will possibly make things more complex for the interoperability of client applications. Just my 2 cents of “let’s not try to reinvent the wheel each time”. Ludo -- Ludovic Poitou http://ludopoitou.com From: Emmanuel Lécharny <[email protected]> Reply: Apache Directory Developers List <[email protected]> Date: 8 March 2016 at 00:26:11 To: [email protected] <[email protected]> Subject: Re: nbSubordnates, nbChildren, was: Work in progress... Le 07/03/16 21:29, Howard Chu a écrit : > Emmanuel Lécharny wrote: >> Le 07/03/16 20:45, Stefan Seelmann a écrit : >>> On 03/06/2016 02:49 AM, Emmanuel Lécharny wrote: >>>> I think it will be very useful for studio, when running against >>>> ApacheDS, as once can now expose the number of *real* childrens and >>>> subrdinates without having to fetch them from teh server (more >>>> important, we won't be limited by the SizeLimit that can be set - >>>> typically 1000). >>>> >>>> I wish we can have the same feature added to OpenLDAP and the other >>>> servers... >>> Well some servers support something similar: Novell has a >>> "subordinateCount" AT, SunDS/OpenDS/OpenDJ have a "numSubordinates" and >>> "hasSubordinates" AT. numSubordinates is defined in an expired draft >>> [1] >>> and has OID 1.3.6.1.4.1.453.16.2.103 assigned. hasSubordinates is even >>> defined in X.501 and has official OID 2.5.18.9 assigned. >> I took the idea from SunDS, leveraging the fact that we have the >> information available. >>> >>> In Studio we use those attributes but only to indicate if an entry >>> contains children or not and ot make the item in the tree expandable >>> or not. >> >> Good >>> >>> Maybe we can add at lease hasSubordinates additionally, then other LDAP >>> clients that already support it can leverage it. >> >> I can add the hasSubordinates AT easily. >> >>> >>> I think numSubordinates and subordinateCount only mean the number of >>> direct children, whereas our nbSubordinates means all. >> >> Because we have the nbChildren that gives the direct number of children. >> >>> >>> I think in Studio we can add support for those, we can extend the >>> number >>> shown for an entry like that: >>> >>> ou=users (1000/23456/456789) >>> >>> which means 1000 entries fetched, out of 23456 direct children out of >>> 456789 total subordinates. >> >> Sounds like a good idea, although it's a bit heavy. How about having >> just the number of children as a default, and a hover to give the number >> of fetched and subordinates ? >> >> Most of the time, people won't fetch the entries. > > OpenLDAP has supported hasSubordinates for quite a long time. The > current back-mdb has the necessary info to provide numSubordinates but > we didn't see a need to implement it. Same here, but in Studio, the need is obvious : when you expose a set of entries, you have no clue about those having children, and no clue about how many of them (actually, as Stefan says, it depends on the diretcory server Studio is talking to). So the only way is actually to read the entry's children to have this count. The hasSubordinates is clearly good to have, as it allows Studio to at last inform the user that there are some entries below. ApacheDS had none of hasSubordinates/nbChildren/nbSubordinates exposed, leaving us in a position where studio was offering a better user experience with any other LDAP server :/ Now, assuming you don't have the number of subordinates (or children) available, you won't get it by fetching teh entry's children because you may reach the server's limit. Using a PagedSearch to browse all the children would not only be a tehcnical non-sense, but will also only work if teh remote server supports such a control. Bottom line, haing at least the number of children returned within each entry offers us some insight. There is also one frequent need from LDAP users : "give us the number of children, so that we can manage the presentation properly". > back-bdb/hdb don't have the info for numSubordinates and since they > are deprecated, we would not be adding anything to them any more. > > (Actually, I don't know which you're referring to. They could all > provide the number of immediate children; the total number of > subordinates in the subtree is only directly available in back-mdb at > the moment.) I do think that the number of direct children is really the important information. The number of subordinates (ie children and all the descendant) is quite cosmetic. It's more about being able to knwo how much entries your database has when fetching the context entry. We have this information in ApacheDS, it was easy to provide it at the same time we provided the nbChildren. Last, not least : the cost of providing this information is not null. We have to do a fetch on the Rdn index for every entry, which adds an extra cost of 10% the time it takes to grab the same entry without this attribute. We could have cached this information, or grab it while constructing the DN, but that would have meant a way more complex refactoring and a complicated entry/DN cache management... Not worths the effort, IMHO.
