[python-ldap] Supporting syncrepl (and fixing LDAPObject.results{, 2, 3, 4})

[Ondřej Kuzník]

Hi all,
this has been on my list for a while and definitely needs fixing
for 4.0. The way we parse results is broken, we cannot process
intermediate responses properly and the results are n-tuples where n
often depends on the arguments passed to .result4(). Also the way
LDAPmessage_to_python works, we lose the order messages actually came
in, that's a no-no for syncrepl at the very least. And .result() callers
shouldn't get an exception when a non-zero result message is received,
losing all other messages in the process forever.

This needs work on all levels of the module:
- C code needs to expose a new results interface that returns everything
  in a common interface with common fields like result, message,
  references, OID, controls etc. where appropriate.
- by the time they are returned from the Python side, each response should
  be an instance of LDAPMessage subclass as appropriate with controls,
  intermediate and extended messages fully decoded if a decoder is
  available. It will be possible to check the result code and raise an
  appropriate exception as usual for each message derived from
  LDAPResult.

This is a stepping stone towards a similar overhaul of the request API,
removing some of the distinction between the _s and non-_s variants as
well as resiter eventually enabling asyncio compatible operation (see
my asyncio wrapper[0] for an example how the API could look like).
Of course, it will be fun to make sure we don't break any backwards
compatibility in the 3.x interface for others.

Comments on the design and volunteers to help with this are welcome.

[0]. https://git.openldap.org/openldap/syncmonitor/-/blob/master/syncmonitor/ldap_wrapper.py

Regards,

-- 
Ondřej Kuzník
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP