[glue-wg] 1st Draft of the GLUE 2.0 LDAP Implementation

[Burke, S (Stephen)]

glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On Behalf Of
David Horat said:
> I just commited my first draft, which does not include any foreign
keys. You can check it at our SVN:
	http://forge.ogf.org/svn/repos/glue/LDAP2/

I'm just getting back to this after CHEP and Easter ... I'll reply to
some of the individual mails, but I want to start with the question of
how you've dealt with inheritance, because looking at your draft it
seems to me that what you have is the worst of both worlds. As I
understand it what you've done is not to use LDAP inheritance, i.e. the
objects don't carry the parent objectclass(es), you just explicitly put
the inherited attributes into the derived objectclass definitions.

  I can basically see two downsides to that, which go in opposite
directions. One is that because the objectclasses aren't inherited you
can't do a generic search for all objects of a given type - for example,
doing objectclass=Service won't get the derived ComputingService and
StorageService objects.

  On the other hand, keeping the inherited attribute names is
potentially confusing. For example, in ComputingShare you have
attributes called EntityName, ShareDescription and
ComputingShareMappingQueue, so if people are just working with the
ComputingService attributes, e.g. in the JDL, they will have to remember
that some attributes are inherited and hence have different name
formats.

  Another point maybe relates particularly to the ID, which is that if
the ID of every object is called EntityID you can't tell what kind of
object it refers to, and we need a globally unique ID space. I'm not
immediately sure if that's a plus or a minus but it's certainly a change
from current practice, where the UniqueID of each object type has its
own name and where the IDs of objects of different types can be and
often are identical.

  It seems to me that we should go one way or the other, either do it
properly using inherited objectclasses or redefine and rename the
attributes for each derived type. In principle it could be done
differently for each case but that might well be even more confusing and
I'm not sure what the argument would be for that - except perhaps for
Entity where I could see a case for not explicitly inheriting it even if
everything else were done with inheritance.

  I think my inclination is to use "real" inheritance because it will
help in writing general tools, e.g. to query for the endpoints for all
services - the alternative will be to always have to remember to add
extra filter clauses for the special types, and to add more extra
clauses if we ever introduce any more derived types.

Stephen
-- 
Scanned by iCritical.