[glue-wg] LDAP Rendering

[David Horat]

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.

Regards,
David

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.
>
> Stephen
>
> --
> Scanned by iCritical.
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/glue-wg
>



-- 
David Horat
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/
Profile: http://linkedin.com/in/davidhorat