Re: LDAP shall speak unto LDAP + first cut at best-first searching

[Simon E Spero <[e-mail]>]

Tim - 

Dealing first with the request groupings; The reason I'd suggested allowing 
requests to be grouped together is to allow a group of messages to be handled
with the same message id. 
 
 In LDAP, the main job of a message id is to allow the client to associate
responses with streamed requests. Since LDAP operates over a reliable 
transport layer, messageID has no other role.

In CLDAP, messageID has to do the work of the transport layer as well. 
Suppose we had send of a search request with messageID 123, and the server
found six matches. With CLDAP as defined now, each of those results would be
sent back with messageId 123. However, the client has no way of knowing that
there are six replies on the way; it might only recieve four of them, or packet
duplication might mean that seven replies turn up. 
 There is no way for the client to detect the loss of a message where 
multiple responses are sent, and duplication can only be determined by 
comparing the actual message body.

I'm not convinced that allowing grouped requests is the best solution to the
problem (it hurts streaming), but it does seem to be one of the simplest,
and for cases with more complex demands there's always LDAP to fall back on 
(There's no point in re-inventing TCP; I'm no Van Jacobsen).

I'll try and answer your other question in another message

Simon