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.
