glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@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/
OK, the second general question that I haven't noticed being discussed is how we structure the DIT. Your example objects seem to just have e.g. "dn: EntityId=testExecutionEnvironment,o=grid" which isn't really viable! As I've mentioned in the past I think there may be a good case for saying that we don't require a given DIT structure, or at least allow some degree of flexibility to restructure it. Since every object now has an ID I think it's possible to say that objects should always be referenced by ID and not DN - which also relates to the ChunkKey question. However, even if we take that view we should clearly have some recommended structure (or structures). A specific question for me is whether we want to introduce some extra dummy object(s) to allow for grouping. At the moment we group by site, but everything below that is basically flat, so e.g. at CERN you have 110 GlueService objects hanging off the mds-vo-name=CERN-PROD node - and 4473 objects in total! If we group by Service object with other things below that then the structure will improve, but there may still be quite a number of Services, so I think it could be useful to introduce some kind of ServiceGroup object which would allow related services to be grouped together. You can get the same kind of thing at lower levels - an obvious example is that there could be a very large number of ComputingActivity objects, so at the very least you might want to group them all under a dedicated node and not have them hanging directly off ComputingService. We also have a particular problem with the UserDomain object, which doesn't really fit with the current site-based publishing model. Who would we expect to publish that information, and where would they put it in the tree? Stephen -- Scanned by iCritical.