[glue-wg] LDAP Rendering

[David Horat]

Thanks Laurence and hello to everyone!

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 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.

If you have any comments or suggestions, do not hesitate to do them. If you
want to wait until the first draft is out, you may. I expect to have it done
in one week, thus by next monday.

IMPORTANT: To make it easier for all us to comment on it, I created a wiki
page[2] where we can all discuss this issues. Please use it.

Links:
[1] http://mysqldump.azundris.com/archives/74-LDAP-is-not-relational.html
[2]
http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GLUE2LDAPDiscussion

PS: Laurence, remember your motivational stickers! ^_^

Regards,
David


On Fri, Mar 20, 2009 at 4:48 PM, Laurence Field <Laurence.Field at cern.ch>wrote:

> David Horat from CERN will start looking at the LDAP schema rendering. Does
> anyone have any comment/suggestions before he gets started?
>
> Laurence
>



-- 
David Horat
Software Engineer specialized in Grid and Web technologies
IT Department – Grid Deployment Group
CERN – European Organization for Nuclear Research » Where the web was born

http://davidhorat.com/
http://cern.ch/horat
http://www.linkedin.com/in/davidhorat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/glue-wg/attachments/20090323/a15c8587/attachment.html