directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: Last needed feature for teh API : referral handling
Date Mon, 14 Nov 2016 10:18:06 GMT


Le 14/11/16 à 10:42, Radovan Semancik a écrit :
> 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 connector.

This is exactly what is the first option. We reuse the original creds to
open a new connection. It's not complicated, but you still have to take
care of infinite loops.
>
> 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. 

We currently don't have that, and yes, it would be a good thing to add
this to the API.

> 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
Agreed...

> Not to mention the error handling, which in the current API stale will
> become a nightmare. 

And which has to be addressed in any case in teh current implementation !!!

> 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. 

Spot on.

> To summarize: it is much much harder than it seems.

Agreed.

>
> 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.


I'm pretty much leaning toward this direction. It always bothered me to
have to add referral handling in the API as it is, but I always told
myself "we have to do it...". So I'm teared in two opposite direction.

> 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.
>
Having a different perspective from someone who haven't been involved in
the API design for the last 10 years (yes, 10 years...) is really an eye
opener.

Let's get the 1.0 out as is, I think that it's "good enough" at the moment !

Many thanks Radovan, for the insight !

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org


Mime
View raw message