Schema support

Hans Aschauer Hans.Aschauer at Physik.uni-muenchen.de
Wed Apr 3 19:42:36 CEST 2002


On Wednesday, 3. April 2002 16:37, you wrote:
> Hans Aschauer wrote:


>  > (defined in ldap_schema.h). For thread safety, they simply use the
>  > _ldap_call() function (Michael, is this a good idea?).
>
> I don't know if it's good idea. But it was the best idea I came up
> with. So it's the right way to do it.

:-)

[...]

>  > * The class rootDSESchema (looking for a better name...), which
>  > takes an initialize()'d and simple_bind_s()'ed ldap object.
>
> You should not do initialize() and simple_bind_s() because it could
> be a waste of resource and the root DSE and/or schema could be
> subject of access control.  The application is responsible to make
> the connection and set up the right bind context => simply let the
> application pass in a instance of ldap.LDAPObject and solely do the
> search_s() calls within your class.

Ooops, that was exactly what I meant. Just pass an initialized and boud 
ldap object.

>   > The constructor
>  >   queries the rootDSE and fills the attributeTypes, objectClasses,
>  >   ldapSyntaxes, and matchingRules which are known by the ldap
>  > server into 8 dictionaries: for each of the four classes, there is
>  > one dictionary which takes the oid's as keys (these are those
>  > funny "1.2.3.4" things, which are supposed to be unique), and one
>  > dictionary takes the names as keys. The latter is necessary, since
>  > for example, in objectClasses, the allowed or required attributes
>  > are referred to by name rather than by oid.
>
> I'd like to have a single OID registry since OIDs are really unique.
> There are no collisions. Simply map the OID in string notation to the
> schema element instance with a single dictionary. The reverse mapping
> can also be done by a single dictionary. I don't think that people
> are using the same names for attribute types and object classes.

You are right, this will really simplify things... 

[...]

> BTW: Theoretically the sub schema sub entry can be different in each
> part of the DIT. Therefore an application has to query the
> subschemaSubentry attribute each time it uses the schema somewhere.
> Schema can be cached if the DN in subschemaSubentry attribute is the
> same. Maybe the OID registry could be a nested dictionary...

You write of this possibility as a theoretical one. Do you know of any 
ldap server that implements this? Hmm, if I think about it, this is 
really usful as soon as referrals are being used. Are there other 
real-world situations where you (or someone else) have seen this?

Maybe one should not automatically query the schema entries for every 
branch of the DIT, but only at "important" branches. If there exists no 
schema description at the desired level of the tree, the closest one is 
aquired (in Zopista speach) by climbing down the tree toward its root.

It would then be up to the application writer (or some clever logics) 
to determine which branch is considered important. 

Would something like this make sense?



-- 
Hans.Aschauer at Physik.uni-muenchen.de




More information about the python-ldap mailing list