[glue-wg] LDAP Rendering
Maarten Litmaath
Maarten.Litmaath at cern.ch
Wed Mar 25 10:57:41 CDT 2009
Hola David,
welcome to the club! Your plans make sense to me, but I hope others will
comment on the technical aspects as needed (maybe next week after CHEP).
One comment inline below.
> After taking a deep look at Glue 2.0 official specification and the last
> LDAP schemas, I have noticed that there are several differences between
> both of them and they do not reflect the specifications entirely, thus I
> have decided to start them from scratch.
>
> After some research on how to deal with LDAP schemas, how was Glue 1.3
> done, several suggestions from Laurence and some ideas I already have,
> my first draft will be as follow:
> - Each class in the specifications will have its own schema file, which
> is much better for development purposes.
> - One bash/python script will compile them all to create a single schema
> file, which is much better for production purposes.
> - I will create one ldif file per object as an example and to use them
> as unit tests.
> - All LDAP objects and attributes will be prefixed with the string
> 'Glue' to ensure some backwards compatibility and make it easier to
> change the current applications. This can be changed in the future.
> - I will represent the specification in the schemas as closer as
> possible to be much easier if changes want to be made or questions arise
> (as they will).
> - Thus, I will follow the exact inheritance done in the specifications.
> This inheritances will be done at the object level, so we don't need to
> provide several objectClass when we create a new object. I read
> somewhere that this was better because we ensure inheritance from the
> specifications, although it can be changed in future versions.
> - Since our specifications is relational and LDAP is NOT relational, I
> am still unsure how to implement this properly in LDAP. I am used to
We probably will have to resort to "tricks" as used in GLUE 1.x.
For example, an object can refer to a logical parent via a ChunkKey
and to an object with a different ancestry through a ForeignKey.
As we are still defining the LDAP rendering, we might invent further
such notions as needed or desirable (e.g. for clarity or elegance).
> implement this in SQL but not in LDAP. I have read that, simply, you
> shouldn't try to make something relational into LDAP [1]. So if any one
> have suggestions here, I will be glad to hear them.
> - Very few attribute types of the specification can be mapped directly
> to LDAP types, so I will just follow the ones used in the last schema
> definitions. LDAP is just not prepared for all the types that we use in
> the specifications and other integrity mechanisms should be used.
> - The only mandatory attribute that I will specify is the GlueEntityId
> (aka the 'key') and all the others will be optional as it is implemented
> in the last schemas. This can be changed in future versions.
More information about the glue-wg
mailing list