Message 8/484 From Marat Fairuzov Sep 11, 98 04:00:00 pm -0500 Date: Fri, 11 Sep 1998 16:00:00 -0500 (CDT) Subject: Re: MDS component software format suggestions ... Hi, Juan, I forwarded your suggestions (thanks btw) to Ian Foster, and showed them to Gregor Laszewski personally. I myself agree with them, and my proposal did include a base class for "generic" parameters, and subclasses, and some other things. Unfortunately, the decision is not up to me. Maybe in the future Globus releases the software object format will be different. As for modifying things yourself - I'm not sure. If you run your own ldap-server, for your own MDS subtree, then probably you can do that, otherwise - highly unlikely. Marat On Mon, 7 Sep 1998, Juan Villacis wrote: > Hi Marat, > > Ok, Andrew and I discussed ANL's tentative MDS format, > and we have a few suggestions. > > First, we feel that there should be a clear delineation > between environment-specific and environment-independent > attributes in the MDS format. (The tentative format > blurs the distinction, e.g., GlobusSoftware class contains > both "description" and "executableDirectory" attributes.) > We outline these observations below: > > 1) database efficiency > > By factoring out common, environment-independent attributes > from each GlobusSoftware class (and placing it into another, > say, superclass or separate class) the size and management > of the MDS database can be optimized (e.g., less duplication > of information, less places to update information, etc.). > > 2) clearer/cleaner MDS utilization > > The searching for components in the MDS database could be done > in stages. The first stage would involve finding a component > that matches the problem requirements (e.g., "I need a matrix > solver component for my application"). This is general, and > independent of runtime considerations. The second stage would > entail matching runtime requirements (e.g., "Ok, now that I have > a component, which machine(s) is it available on that satisfy > X, Y, and Z constratints?") Staging allows the user of the MDS > to defer instantiation of components until they are satisfied > that the "right component for the job" exists. The separation > of environment-specific from environment-independent attributes, > could reduce the search time for finding that "right component". > > Second, is there an "officially" sanctioned mechanism for > adding classes to the MDS format? E.g., are there extensions > that are provided so that we can add/graft our own CAT-specific > component software format to/on the MDS format? Or are the > LDAP mechanisms sufficient (e.g., unioning of attributes)? > > Thanks! > > -juan