[glue-wg] LDAP Rendering

[Burke, S (Stephen)]

Paul Millar [mailto:paul.millar at desy.de] said:
> Having read (only the relevant bits of ;-) RFC-4511 I 
> couldn't find anything 
> to suggests that one cannot use substring match rules in an 
> extensible filter.

My experience was more practical, I tried it and observed that it didn't
work! However, with more time to think about this I'm not sure it's
directly relevant anyway. The current use for the chunkkey is to relate
objects with only a LocalID to their parents, but we now have global IDs
for everything so I think we can just use the same kind of key for all
relations. At a quick look I don't see any case where we have both
parent and non-parent type relations between the same object classes,
but if we do we should probably treat them as independent relations.
(Hmm ... AdminDomains? Sites belong to both EGEE and LCG, but neither of
those is a parent of the other, so EGEE -> LCG has a different status to
EGEE -> DESY. But looking at the diagram we don't seem to allow for peer
relations at all, so EGEE can't relate to LCG :)

  Anyway as I said earlier this is closely coupled with the question of
how we structure the DIT - my personal preference is that we should try
to avoid prescribing a particular tree, which would imply that you
shouldn't need to do extensible queries. Also the schema is rather more
complex than a tree can capture so I think we're bound to end up with
relations that go outside it - e.g. Benchmark seems to be a "child" of
both ExecutionEnvironment and ComputingManager.

  What we may perhaps want to think about is whether we might want any
"double hop" references. For example, ExecutionEnvironment is not
directly related to ComputingService (or DataStore to StorageService).
Obviously you can get the link by doing two queries, but if it's likely
to be a common thing it could be useful to have it explicitly?

> However, even this is immaterial since clients MUST NOT (as 
> in RFC 2119) conduct wildcard searches against the DN.

I take your point, but there are different grades of clients - I often
construct ad-hoc queries which use properties I happen to know are true
(or maybe just "mostly true") even though they aren't mandated by the
schema. That would be naughty in real production code, but can be useful
on the fly. And conversely  I don't think I've ever used an extensible
query in a real-world case, only to test it.

Stephen

-- 
Scanned by iCritical.