[glue-wg] LDAP Rendering

[Paul Millar]

On Wednesday 25 March 2009 16:57:41 Maarten Litmaath wrote:
> > - 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).

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.