>> In looking
>> through the sources, it appears the information is never preserved.
>> I locally hacked my copy of LDAPObject.c to make ldap.result()
>> return a 3-part tuple of (result_type, result_data, result_msgid),
>> where result_msgid = ldap_msgid(msg) after the msg was determined
>> to be good.
>
> Please provide a patch.
I've attached the diff below to the change I was testing in
Modules/LDAPObject.c. It is not a complete fix, as I still
need to go through the rest of the code to change the result()
return handling to deal with the 3 element tuple. The hack was just
a quick proof of concept change to see if I could get my proxy
server to work.
I'll work up a more complete patch in a couple of days. Honestly,
I half expected this idea to be rejected. Won't changing this
return value break any 3rd party code that uses ldap.result()
when they crack out the elements of the return tuple? I must
confess that I am new to Python (and LDAP), so perhaps I'm
asking a stupid question.
>> I need the message ID to match up the reply with the
>> originating request context.
>
> This would also be very handy for a completely async LDAPObject
> implementation which dispatches results to calling threads without having
> to
> use thread locks around each _ldap call.
I think I follow that, but it's a bit over my head. I'm just looking
for a way to lookup the client who's proxy request this reply was for.
Regards,
K^2
|
