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