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.