Re: Thinking about operational attribute numSubordinates...

[Pierangelo Masarati <masarati@aero.polimi.it>]

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

I note (after playing with a gross implementation of the 
hasSubordinates) that the operational attributes generated 
on the fly (like hasSubordinates and subschemaSubentry
itself) cannot be used in filters; extra hacking is required.

I'll think about a way to have these attributes available
whenever required in a reasonably efficient way; I think
we first need to decide whether this requirement is a MUST
or we can live without.

Pierangelo.