directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <pierre.sm...@gmail.com>
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 <
radovan.semancik@evolveum.com> 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
> evolveum.com
>
> Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com/>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

Mime
View raw message