directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radovan Semancik <>
Subject Re: Last needed feature for teh API : referral handling
Date Mon, 14 Nov 2016 09:42:09 GMT
On 11/12/2016 06:41 PM, Emmanuel L├ęcharny wrote:
> Now, we have two options here :
> - we let the user take care of the credentials, and that means 'follow'
> is not an option.
> - we add some configuration in the conection to let the API creating a
> connection using distinguished credentials based on the targetted serv

I'm not sure what the first option really means. Do you mean that the 
API user should check for REFERRAL in the result code and react by 
re-starting the operation on different server? If that's what you mean 
then it is actually not that difficult to do. I have done it in the LDAP 

Besides, every full-featured LDAP client needs quite complex management 
of connections. E.g. there needs to operation fail-over between several 
replicas. I.e. the API client should be able to configure several 
hostnames and the API should be able to load-balance of fail-over 
between them. This is a mechanism that is very similar in nature to 
following the referrals. However, I would not pollute the LdapConnection 
with that. The LdapConnector is already quite complex. And referrals and 
those similar features would add significant complexity. Not to mention 
the error handling, which in the current API stale will become a 
nightmare. And we will need to think about connection lifecycle. Hi-perf 
client definitely would NOT want to open a new connection for each 
referral and then close it immediately. Some some connection "pooling" 
is needed. To summarize: it is much much harder than it seems.

I would suggest this: Let's forget about referrals in API 1.0. There is 
a way how the user can do this if needed. In API 2.0 let's think about 
creating something like ConnectionManager. A dedicated class that can be 
configured with multiple connection parameters, than can implement 
connection lifecycle strategies and so on. The manager can open several 
LdapNetworkConnections internally. The ConnectionManager can implement 
the LdapConnection interface, so using this can be mostly transparent to 
API users (except for its instantiation and configuration). This is the 
approach that I have used in my ConnId LDAP connector and it seems to 
fit well.

So, in the end the user will have a choice: Use "raw" 
LdapNetworkConnection and do the connection and error handling in a 
completely custom ways or use ConnectionManager and let the API do the 
smart stuff. One way or another the "main" code will use the operations 
from LdapConnection interface.

But this is not a simple thing to do. I would suggest not to hold the 
1.0 release and plan this for 2.0. For this to work well we will need to 
improve the error handling code anyway.

Radovan Semancik
Software Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message