Hi Stephen et. al. As it seems that we are having some difficulty trying to go from the what is specified in the document to what we expect the LDIF to look like, I would suggest that we try to work backwards and as such have uploaded some initial examples of the LDIF to the SVN repository. http://forge.ogf.org/svn/repos/glue/LDAP2/examples/ These examples were created by taking the attributes and groupings from the document but using a pragmatic approach based on my experience with Glue 1.3 to create the resulting LDIF. If we can agree on what the resulting LDIF should look like then we can figure out the best way to go from the document to what we what which may result in us making some modifications to the specification. If there are any changes that you think should be done, i would suggest that you copy the file and rename to include your initials. We can then use diff to compare the files. Laurence
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Laurence Field said: As it seems that we are having some difficulty trying to go from the what is specified in the document to what we expect the LDIF to look like, I would suggest that we try to work backwards and as such have uploaded some initial examples of the LDIF to the SVN repository.
OK. One practical comment, it may be useful to remove most of the regular attributes as they aren't really germane to this apart from the general naming style, and it might help us see the wood rather than the trees (or possibly vice versa :). Also you don't seem to have done the inheritance consistently, was that intentional? E.g. the ComputingService has "objectClass: Service", but the ComputingManager doesn't have "objectClass: Manager". Stephen -- Scanned by iCritical.
Yes, this was intentional as the Manager class was just abstract and there was very little commonality between the Computing Service and Storage Service. Laurence
Also you don't seem to have done the inheritance consistently, was that intentional? E.g. the ComputingService has "objectClass: Service", but the ComputingManager doesn't have "objectClass: Manager".
Stephen
Laurence Field [mailto:Laurence.Field@cern.ch] said:
Yes, this was intentional as the Manager class was just abstract and there was very little commonality between the Computing Service and Storage Service.
OK - so your principle is that abstract classes have no objectclass but concrete classes are inherited? (I'm not disagreeing, at least at this point, just trying to understand what you've done.) Next comment, your relations don't seem to match what's in the schema, e.g. you relate ExecutionEnvironment to CService rather than CManager and CShare, and the CShare-CEndpoint relation isn't there in either direction. Stephen -- Scanned by iCritical.
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Burke, S (Stephen) said: OK - so your principle is that abstract classes have no objectclass but concrete classes are inherited?
Actually I think it was a mistake to make Manager abstract, unlike Share and Resource it's useful as it is and indeed StorageManager doesn't add any attributes ... still, probably not too important. Stephen -- Scanned by iCritical.
participants (2)
-
Burke, S (Stephen) -
Laurence Field