[glue-wg] Problem with LDAP binding inherited foreign-keys

[stephen.burke at stfc.ac.uk]

Paul Millar [mailto:paul.millar at desy.de] said:
> One potential problem is that the clients don't know which 
> attribute to use when querying.

I guess the formally correct answer would be that it depends what kind of query you're doing, but since LDAP has no real data typing or object orientation anyway it seems like an unnecessary complication.

> Consequently, the info-provider should 
> publish both, just to be sure and the client has to query both, again, just to be sure.

For the time being I think providers should publish both. As far as I know we have no clients yet (except the saga service discovery api?) so it should be possible to steer those in the right direction from the start.

> For me, I feel the risk of people publishing them, or 
> querying against them, 
> is greater than the risk that we remove them and subsequently 
> discover a use for them.

Perhaps, but for now I think we're constrained anyway by backward compatibility.

> We could take a smooth-transition approach (like one would 
> with a production service) or a big-bang approach.

It *is* a production service! The schema is deployed in resource, site and top-level BDIIs around the grid. The information published into it may be a beta-test, but the information system itself is in production so we do need to care about backward compatibility.

Stephen
-- 
Scanned by iCritical.