At 02:47 PM 10/7/2005, Howard Chu wrote: >Kurt D. Zeilenga wrote: >>>And in ldap_parse_result in libldap/error.c, as I've already pointed out, we >>>queue responses with their originating requests. Any LDAP Request can only >>>have one Result message, regardless of how many intermediate messages may be >>>included. So it appears that all accomodation for this >>>LDAP_MORE_RESULTS_TO_RETURN error code is just excess baggage. >>> >> >>The only thing I can think it exists for handling of >>message chains containing responses in reply to >>multiple requests. >> >> >Hmmm. But libldap never constructs chains in such a fashion; responses are >only chained to their originating request. And there are no APIs for an >external caller to link two separate chains together.
What about the case where ldap_result(3) is called for any and all? The message chained returned could contain responses from multiple requests. >Also, in the C API draft section 14 "Handling Errors and Parsing Results" it >says "If a chain of messages that contains more than one result message is >passed to these routines the always operate on the first result in the chain." >And more importantly "If a value other than LDAP_SUCCESS is returned, the >values of all the result parameters are undefined." >So if you somehow got hold of an aberrant chain with more than one result in >it, our ldap_parse_result() would parse the first result (as expected) and >then discover the subsequent result, then return LDAP_MORE_RESULTS_TO_RETURN >which would totally invalidate all the parsing it did on the first result. Given how I think it was meant to be (which may not be how it was meant to be :-), it likely should have said "LDAP_SUCCESS or LDAP_MORE_RESULTS_TO_RETURN". >Obviously trying to make sense out of things based on an old broken API spec >may not be very fruitful. But one way or another it should make more sense >than it currently does. I concur. I suspect few if any clients actually deal with LDAP_MORE_RESULTS_TO_RETURN as (I believe) was intended. >-- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/
