opening a connection with more than a single server

[Jens Vagelpohl]

>> i had no idea that this ever worked, but apparently (i verified it with 
>> python-ldap 1.10alpha3) ldap.open used to accept a hostname string as 
>> argument with more than one LDAP host, separated by whitespace. this 
>> worked in a failover fashion where if one became unavailable the next 
>> one would be used to execute queries.
>
> 1. You have to decide what you want. You requested the old "parameter 
> signature" for ldap.open(). You remember? Think of defining the port 
> number...

this actually doesn't have anything to do with my earlier complaints about 
ldap.open. i'm just saying that apparently back in the 1.10 days ldap.open 
never checked the parameter and passed it straight to the ldap libraries, 
which would interpret it as "if the first server is dead just use the 
second".


> 2. I'd recommend you drop support for old python-ldap and use 
> ldap.initialize() directly. That's far more powerful anyway. Hmm, I would 
> have to remove/modify the is_ldap_url(uri) in the wrapper function for 
> handling the space separated list. But that's least of a problem.

my software is written so that it attempts to determine what version of 
python-ldap is in use and behave accordingly. anything that is not version 
2 and above uses ldap.open, 2.x uses ldap.initialize. simply dropping 
support for ldap.open is not an option, most everyone i know still uses 1.
10alpha3. but apart from that' that's not really my point. i'm just 
wondering if this "server fallback" behavior could find its way back into 
python-ldap2, regardless of connection building method used, because it 
seems it is supported by the OpenLDAP libraries and i am thinking it is a 
useful behavior. that's all.


> 3. IMHO it can't be used for fail-over. AFAIK simply the connection is 
> established to the first host reachable. You could argue that it works 
> kinda fail-over-like if you re-open the LDAP connection for the requests 
> all the time. But if you have a persistent connection you have to 
> implement fail-over by catching ldap.SERVER_DOWN. (I'm currently thinking 
> about sub-classing ldapobject.LDAPObject for this purpose. Note that 
> fail-over means repeating the whole connection-establishment sequence 
> after connecting to the replica).

it's true that the first available connection is used, and my software 
actually does re-open the connection every single time. so for this use 
case it does work like failover.

if i remember correctly i had at one time tried to come up with a way to 
test whether a given LDAP connection object was still good for use, but 
could not find anything that would not already involve making LDAP queries.
  so i assumed the difference in overhead was not that large. let me know 
if i am way off-base here, i could be talking out of my rear end. i have 
never experimented with long-lived connections. i am all for improving 
performance, if you can show me a good way to test existing connection 
objects and tell me that it is indeed faster to do it, i'm all ears.

jens