On 07/14/2015 12:12 PM, Pierre Smits wrote:
Is that an achievable goal? Crappy servers pose so many exceptions to the rule, that any project, trying to realise a client solution, will eventually find that has shot itself in the foot. Of course, no one can argue with a contributor scratching his own itch. But shouldn't this be done in a separate dev branch, so that trunk isn't affected until such an integration is tried, tested and accepted?
It looks like it is not so bad. What we mostly need to do is have an option to disable various syntax/semantics checks (e.g. like this check for OID). And maybe some other things, such as explicit enumeration of attributes to get from root DSE. But this may be generally useful as an optimization anyway.
I've tested several LDAP servers during part months. And it looks like the current API only works with ApacheDS in the strict mode. OpenLDAP might be also to be OK, but may need some fixes as it looks like even RFCs themselves have lots of exceptions and not all of them are implemented in the API. All other servers that I have tested fail miserably and require relaxed/quirks mode to be able to parse the schema.
So I think is it not a question whether we want to have a clean API or not. It is more a question whether we want to have an API for ApacheDS (maybe OpenLDAP) .... or whether we want to have API that is also useful for other major servers that are out there in the wild. We already have relaxed/quirks mode. Then why not extend it when the required changes are small?
But I agree that if there is a need for a brutal changes to the API then a separate branch might be really required. But now all the fixes were practically only changes in a couple of source code lines and mostly encapsulated inside their classes (except that pulling up of methods to interface - and that was the reason I was asking for review). I think that is quite safe to do in trunk. For now.
-- Radovan Semancik Software Architect evolveum.com
