Re: Thinking about operational attribute numSubordinates...

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

There are two operational attributes to consider, hasSubordinates
and numSubordinates.  Both of these come from X.500 pilots.
hasSubordinates eventually found it's way into X.501 (3rd edition).

14.4.4 Has Subordinates operational attribute
  The hasSubordinates operational attribute indicates whether any
  subordinate entries exist below the entry holding this attribute.
  A value of TRUE indicates that subordinates may exist. A value
  of FALSE indicates that no subordinates exist. If this attribute
  is absent, no information is provided about the existence of
  subordinate entries. The attribute will ordinarily disclose the
  existence of subordinates even if the immediate subordinates
  are hidden by access controls ? to prevent disclosure of the
  existence of subordinates the operational attribute itself
  shall be protected by access controls.  NOTE ? A value of TRUE
  may be returned when no subordinates exist if all possible
  subordinates are available only through a non-specific
  subordinate reference (see ITU-T Rec. X.518 | ISO/IEC 9594-4)
  or if the only subordinates are subentries or child family members.

  hasSubordinates ATTRIBUTE ::= {
    WITH SYNTAX BOOLEAN
    EQUALITY MATCHING RULE booleanMatch
    SINGLE VALUE TRUE
    NO USER MODIFICATION TRUE
    USAGE directoryOperation
    ID id-oa-hasSubordinates }

I would not have a problem with implementing hasSubordinates
in accordance with this specification.   I would have a problem
in implementing numSubordinates without a standard track (or
other stable) specification.

In implementing this, there are two basic approaches.

a) maintain the attribute as part of the entry;
b) compute the attribute when requested.

I favor b.  Namely because a) would be a pain to maintain.

I would suggest that implementation do the following:
  On search into a backend supporting the attribute,
  determine if the attribute is requested.  If requested,
  compute value on a per entry basis by examining the
  oneLevel index associated with that entry.  Pass this
  information to the front end so that the attribute
  can be generated.

The question to be answered is how to pass the information
about.  A hack would be to put a varible in the op structure
which was 0 (not present) or 1 (false) or 2 (true) (set by
the and have backend_operational() generate the attribute
needed.  A better approach would be to think out how such
information, in general, should be passed about.

Kurt