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: Client API Schema support
Date Mon, 26 Jan 2015 13:22:05 GMT
Le 26/01/15 13:38, Radovan Semancik a écrit :
> On 01/26/2015 12:55 PM, Emmanuel Lécharny wrote:
>> In ApacheDS, there are two ways you can update the schema : - though
>> the subschemaSubentry - directly modifying the cn=schema partition.
>> In fact, updating one will update the other. The only little
>> difference (well, little is an understatement) is that cn=schema has
>> a proprietary format, when the DSE has a standard one. This is why we
>> do favor the DSE approach. 
>
> Actually, I do not care at all about schema updates. That is too hard.
> And it is out of scope of loadSchema() operation anyway.
Agreed. I just wanted to give you a bit of insight on ApacheDS.
>
>>
>> At this point, the code will more or less looks like :
>>
>> - check with RootDSE
>> - if it fails, try to get the server vender information
>>    - if we have some, read the schema using the appropriate method
>>    - otherwise, check cn=schema
>>      - for each server we support, try to read the schema, until we get
>> it read correctly
>
> I would suggest not to use vendor data at all unless it is really
> necessary. These can change between product versions. This may be a
> difficult maintenance burden.

Ok, your call. You probably know better than me here.
> I would rather suggest this:
>
> - get root DSE
> - check vendor-specific data in root DSE for known special cases that
> fail with the "automagic" process below (hopefully not needed now, but
> we may need it in the future)
> - try to use subschemasubentry from root DSE. If it works return the
> schema.
> - if that fails, try going directly to cn=schema. If it works return
> the schema.
> - if that fails, try X. If it works return the schema.
> - if that fails, try Y. If it works return the schema.
> - ...
> - if all fails throw an error
>
> Or, if there are issues we can modify it to something like:
>
> - get root DSE
> - check vendor-specific data in root DSE for known special cases that
> fail with the "automagic" process below (hopefully not needed now, but
> we may need it in the future)
> - try to use subschemasubentry from root DSE.
>    - try strict schema parser, If it works return the schema.
>    - try more relaxed schema parser, If it works return the schema.
> - if that fails, try going directly to cn=schema.
>    - try strict schema parser, If it works return the schema.
>    - try more relaxed schema parser, If it works return the schema.
> - if that fails, try X. If it works return the schema.
> - if that fails, try Y. If it works return the schema.
> - ...
> - if all fails throw an error
>
> So, this will prefer servers that follow the standard way. Less
> roundtrips. But it should eventually find the schema for most servers
> in most cases without any configuration. And it is unlikely to break
> with new LDAP server versions and/or product rebranding as vendors
> tend to keep some form of backward compatibility.
>
> This obviously needs some experimentation to get this right ... and
> I'm willing to do it.
>
> BTW, I've just checked that at least OpenDJ and 389ds (and of course
> also OpenLDAP) all seems to support subschemasubentry in root DSE. And
> they all return the schema in what seems to be the RFC format. There
> may be some issues, of course. But it looks like that the support for
> these servers should not be difficult to implement.

I do think so.

The only ticky parts might be with extensions (X-NNN). Not all the
servers support them, and you will have to be able to decode them.


Mime
View raw message