directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <>
Subject Re: 389 Directory Server support in API
Date Tue, 14 Jul 2015 11:00:45 GMT
See inline

On Tue, Jul 14, 2015 at 12:43 PM, Radovan Semancik <> wrote:

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

Good to know that the work done is beneficial to overall optimisation of
the product. I was just asking to get a better understanding, not
condemming in any way.

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

Maybe we can influence those other products to improve their act as well.
Though that might prove disadvantageous to the adoption of our flagship
product ApacheDS.

> 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?
> I am inclined to agree. I am also keen on keeping in mind that this drives
adoption and thus having more contributors to ease your and others' burden.

> 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
> Best regards,

Pierre Smits

Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade

View raw message