> > - Since our specifications is relational and LDAP is NOT relational, I > > am still unsure how to implement this properly in LDAP.

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

Please be aware that, for some time now, there is support for "extensible queries" (see RFC 4515). This removes the need for GlueChunkKey.

For example, to query all GlueSAPath attributes (of objects with objectClass GlueSA) that are children of SE "se.ngcc.acad.bg" (GlueSEUniqueID=se.ngcc.acad.bg), one could conduct the following query, which uses GlueChunkKey:

ldapsearch -LLL -x -H ldap://lcg-bdii.cern.ch:2170/ -b o=grid '(&(objectClass=GlueSA)(GlueChunkKey=GlueSEUniqueID=se.ngcc.acad.bg))' GlueSAPath

However, the same result is obtained without the ChunkKey by using the ":dn:=" extensible query:

ldapsearch -LLL -x -H ldap://lcg-bdii.cern.ch:2170/ -b o=grid '(&(objectClass=GlueSA)(GlueSEUniqueID:dn:=se.ngcc.acad.bg))' GlueSAPath

IIRC, there was an argument for continuing to support GlueChunkKey in Glue v1.3 to allow legacy queries. Moreover, (afaik) there was never an official document describing the LDAP binding for GLUE v1.3 (so nothing to update ;-)

A reason to stop using GlueChunkKey is it's provides the info-providers the opportunity to publish inconsistent information. Instead, the extensible query is always consistent (unless there's a bug in the server software).

Since, GLUE v2.0 is not meant to be backward compatible, I'd say we can safely drop GlueChunkKey in favour of the safer ":dn:=" style queries.

HTH,

Paul.