Re: The LDAP 'list' debate

[Russ Wright <[e-mail]>]

>|    >Another possible solution (and perhaps somebody who has read the spec
>|    >closer than me can comment if it is possible) is for the LDAP server to
>|    >have this "implementation" knowledge built in, and map the LDAP search
>|    >onto list and reads for the relevant part of the DIT (you can work out
>|    >which parts of the DIT are affected algorithmicaly).
>|    
>|    If everyone becomes convinced that LDAP's lack of list realy is a problem
>,
>|    I vote for this solution.  We should push for things that make it easier
>|    for people to write X.500 clients.  I would much rather see extra effort
>|    put into 
>|    into the LDAP server than all the clients (of course I don't have to writ
>e
>|    the LDAP server ;-) ).
>|    
>|    Isn't the point of LDAP to make it easier to write X.500 clients?
>|    
>|    Russ
>|    
>|    
>|    
>
>You have got the point here.
>
>LDAP servers will not have to be written for all "kind of strange"
>big/medium/small
>systems, but DUAs will have to be.
>This mean that it is better to put efforts on writting (one ?) more complex
>LDAP
>server, and have a good time writting DUAs afterwards, than the other way
>around.
>
>More to it, LDAP servers will  written by experts (well, people knowing
>something)
>byt a simple programmer  should be able to write  a DUA.

OK, I'm with you up to this point.


>So I certainly vote for:
>                           LDAP having the LIST operation
>

Well, I lost you here.  We weren't saying that LIST should be added to the
LDAP protocol.  The LDAP SERVER should be smart enough to turn a LDAP
search command into a set of X.500 list and read operations if the X.500
search could not be performed.  This moves the complexity away from the
LDAP client into the LDAP server.  The difference is that the DUA writer
would not have to decide which one (list or search) to use.

Russ