[glue-wg] LDAP Rendering
david.horat at cern.ch
Thu Apr 16 10:44:53 CDT 2009
Since we are using a relational diagram which does not fit in a tree
(that is the reason why we need foreign keys), I would also recommend
not to force the DIT, but rather make recommendations on how to
implement it. Right now Laurence is working on it.
On Thu, Apr 16, 2009 at 5:40 PM, Burke, S (Stephen)
<stephen.burke at stfc.ac.uk> wrote:
> 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.
> Scanned by iCritical.
> glue-wg mailing list
> glue-wg at ogf.org
Software Engineer – IT/GD – Grid Deployment Group
CERN – European Organization for Nuclear Research » Where the web was born
Address: 1211 Geneva - Switzerland, Office: 28/R-003
Phone +41 22 76 77996
Professional Web: http://cern.ch/horat
Personal Web: http://davidhorat.com/
More information about the glue-wg