Schema handling with various LDAP servers (was: fetching the structure / obejctClass defs)

[Michael Ströder]

Hans Aschauer wrote:
> 
>>I'd like to see a base class for a LDAP syntax with a method
>>validate() which is called when setting the attribute value.
> 
> So this would mean that we change the implementation from "syntaxes are 
> instances of the syntax class" to "syntaxes are subclasses an 
> (abstract) syntax base class". Which objects would then instanciate the 
> syntax classes? Maybe some kind of attribute class instances, through 
> multiple inheritance?

This question really drives me nuts. After playing yesterday with 
kind of a hard-coded class-based syntax handling added to web2ldap 
I didn't came to a conclusion whether an attribute should simply 
be an instance of LDAPSyntax class or not. Well, think of matching 
rules. That really makes it complicated.

Frankly, I don't think it's worth the effort. I looked into sub 
schema sub entries of various public LDAP servers (Netscape 4.x, 
iPlanet 5.0, Siemens Dir/X, OpenLDAP 1.x/2.x, Innosoft, etc.) and 
the declaration of syntaxes is so different that it really does 
not make much sense to read and use the syntax and attribute type 
declarations from most of the LDAP servers.

It's a whole mess out there in the real world!

> For objectClasses, inheritance seems to 
> make sense, since they inherit from each other, and I think it would be 
> possible (in python), to build a class hirachy from server information 
> "on the fly".

There's not much you have to do with object classes.

 From my tests I noticed that e.g. declaration of inetOrgPerson 
differs on servers by various vendors (e.g. Dir/X declares 
inetOrgPerson as AUXILIARY class derived from top which violates 
RFC2798).

SubSchema.all_attrs() solves all these issues by resolving all MAY 
and MUST classes for a given list of object classes. Note that you 
can limit retrieval of sub schema sub entry to object classes by 
parameter attrs which usually saves a lot of band-width.

Ciao, Michael.