Paul Millar wrote:
I argued that GLUE probably should allow for the RP being multi-valued, and probably the AccessLatency as well. In WLCG/EGEE we would have a single value for each normally, so that the Storage Class is clear.
I'm not sure what AccessLatency as a multivalue means: I'd push this attribute down to the hardware layer (StorageDatastore/StorageMedia/StorageStorage)
It's possible that we've been talking slightly at cross-purposes. It seems to me that what WLCG means by "access latency" is really the minimum (ie, fastest) guaranteed access latency (MGAL): D0T1 this is nearline D1T0 this is online D1T1 this is online
Yes, in WLCG we want it like that, but I wondered whether it is necessary to insist there be exactly 1 access latency. It does seem to make sense with the current ordered set of values: Online < Nearline < Offline But what about an SRM v1 or a Classic SE that has unspecified subsets of its name space going to tape (current practice): one might want to list both Online and Nearline as potential guaranteed latencies - some files have Online, other files have Nearline as their _guaranteed_ latency. A single value Nearline might suggest that everything goes to tape. Probably devil's advocate, but in GLUE we should be careful with insisting that a particular property shall _always_ hold... Thanks, Maarten