[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ldap
Subject:    Re: LDAP (V3)
From:       adrianthomson () unn ! unisys ! com
Date:       1996-08-27 17:53:12
[Download RAW message or body]

>> Currently the X500 LIST function has not been implemented and I note with
>> disdain that it is not currently proposed to implement this function in V3 
since
>> it is argued that a workaround can be acheived via SEARCH. Has anyone tried
>> implementing LIST and actually measured the time differences between these 2
>> mechanisms ?? The answer is YES I have and I believe that the differences are
>> such that in my view it is essential to implement LIST ASAP.

>Is it not possible to recognise the special case of SEARCH and 
>process it efficiently within the server?  If it is, LIST is not 
>required in the protocol and the problem becomes a local optimisation 
>in the server, not a standardisation one.

There will always be the case however, where someone will want
to perform a search of one level for objectClass=* and pull back
all the attributes in the entries. I don't know what you propose
as the special case (filter:objectclass=*, scope=onelevel would
prevent the above request from working) but isn't your solution 
trying to hack a way around a restriction of the standard?

I don't like having to use the search operation for SEARCH, LIST
and READ - I'd prefer to have the three separated where
each one is optimised. Most LDAP servers convert the LDAP
request to a DAP request anyway, so adding LIST and READ would 
not be that much work, probably the most work would be involved
with handling the protocol.

For cases where a 93 DSA is connected to the LDAP server and
93 access control is in place, isn't a SEARCH going to be 
significantly more inefficent than a humble LIST?

Give me XDS anyday ;-)

Adrian.

[prev in list] [next in list] [prev in thread] [next in thread]