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