MDS Proposed Format: Reply


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