[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: new control for filtering dn attribute values based upon their object class
At 01:12 PM 5/24/01 -0700, Bob Joslin wrote:
Hi Bruce,
Thanks for the reply. One question and one comment in-line:
Bob Joslin
Hewlett-Packard
I am most certainly not an expert when it comes to indexed database
technologies. But from what I think I understand, I'm not sure I understand
why having an index on the objectclass would really help.
Since the LDAP server already knows the DN of the entry in question, why
would it use an objectclass index to determine what objectclasses that entry
belongs to?
I was thinking that if you were filtering based on object classes, then the
object class index could be used. But, you may be right.
I suppose that would work ok, if if the LDAP client were
interested in only one or perhaps two particular objectclasses for that DN.
In that specific case, the server could scan the list(s) of DNs for
that/those partcular objectclass value(s). But that's could be an expensive
operation if there are many entries of that particular objectclass value.
But it seems that if you were interested in serveral or all the objectclass
values for a particular entry, that the search would be very expensive using
the objectclass index.
It seems to me that once you have the DN, the best way to discover the
objectclasses for a particular entry is to examine the entry itself.
It would really depend upon the implementation. Do you apply the control
after the search has been implemented, and then filter out the unwanted
entries, and then create the object class tags in the control response. Or
do you implement the control as part of the search process? I was thinking
the latter. But, if you are doing it after the main search processing,
there are likely to be different considerations. At one time earlier in my
career, I prototyped a CIP Tagged Index Object Server that also responded
to LDAP queries. In that implementation, it would have been
straightforward to implement the object class filtering as part of the
search process. But, different servers would have different constraints
that they have to obey.
>
> >The control then causes the server to only return the DNs that
> >pass that filter?
>
> The control also provides a way for the client to learn the
> object classes
> of the DNs that are returned, in addition to actually filtering
> out some of
> the uninteresting DNs from being returned at all.
Agreed. Although, sadly, some implementations of LDAP don't record
auxillary objectclasses.
BTW, self-servingly speaking as a client, I think what I'd like to see is a
combination of the two ideas. - a filter would be used to filter out the
selected DN based members of a group, and an optional list of attributes
could be returned (objectclass, cn, uid, etc...) for those particular
entries. (I sense cringing by several vendors.) :-)
I agree that this would be useful. I will create a revision of this draft
to include other attributes in the "tagging" area. Would any server
vendors be interested in stepping up to the plate and taking a swing at
this one?
Bruce
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com