[glue-wg] GLUE 2.0 Specification - draft 41 - Working GroupLastCall

[Maarten Litmaath]

Burke, S (Stephen) wrote:

>   As a general comment, the text uses the word "capacity" (or
> "capacities") in many places to mean something like "the ability to
> store data". I think this is a bad choice of word, partly because of
> possible confusion with the Capacity objects and partly because I don't
> think it's really the right word anyway. Also in some places the text
> uses "storage extent" to mean what seems to be something similar, and
> again I don't think "extent" is a very good word. However, I'm not
> entirely sure what to recommend as an alternative - perhaps
> "capability"?

That term is also being used already for something else.
What about "ability"?  (I did not check if it makes sense everywhere.)

>   Service: four of the association descriptions use the word "offers",
> which I suspect isn't really the right word for most of them - for
> protocols it's OK, and maybe for Shares, but it doesn't really offer
> managers (they aren't externally visible) and it definitely doesn't
> offer Capacities, it just has them.

For managers: "is managed by".
For capacities: "has".

>   Manager: Type seems a slightly strange name for the attribute, things
> like "enstore" and "castor" aren't really types. Actually this applies
> to ComuptingManager too although I didn't pick it up there, are "lsf"
> and "pbs" types? Also since both CM and SM have a Type attribute should
> it anyway be defined in the parent Manager entity? (ditto Version). [...]

What about the good old Implementation?!

>   StorageResource: as you might guess I'm still inclined to prefer
> DataStore! Since we have ExecutionEnvironment and not ComputingResource
> this is evidently not a hard naming rule [...]

Either is fine with me.