Hi Jens, all coming back to this topic: add a StorageShare attribute that describes the number of files stored in this StorageShare. This should be optional (mult: 0..1). Unfortunately the original email by Paul got lost, and I don't know if there was some discussion as well at that time, before you remind us this topic. I would like just to discuss the name of this new attribute: something like StorageShareFiles or StorageShareTotalFiles ? let me know, alessandro On 24 August 2017 at 16:28, Alessandro Paolini <alessandro.paolini@egi.eu> wrote:

Hi Jens,

sorry for not replying before: I've just noticed that your message (and the consequent reply by Stephen) finished in the spam folder...

Regarding the P1, I will correct the document, thank you for spotting this (I'm being in vacation since tomorrow till Sep 12th, so in the next two weeks i'm not being able to participate to the discussion).

Regarding P2, P3, and P4 it is not completely clear to me the need, maybe because I look at the GLUESchema as operator/administrator rather then user, and I don't know well the needs of the experiments.

cheers, Alessandro

On 23 August 2017 at 16:45, <stephen.burke@stfc.ac.uk> wrote:

...

glue-wg [mailto:glue-wg-bounces@ogf.org] On Behalf Of Jensen,

...

Jens (STFC,RAL,SC) said: One thing I did not see in this document - but had expected? - was to address Paul's suggestions from November last year. See attached.

We didn't discuss this, but my comments would be:

P1: seems uncontroversial.

P2: The semantics for multiple paths would need to be clear - in the past it was used as a default path on which to write files, if you have more than one it wouldn't be obvious. A more backward compatible approach would be to add a new multivalued attribute for additional paths, then it's clear that the existing one should be the default.

P3: The reason for having a separate Capacity object was that there are potentially many different semantics for what the attributes can refer to. Putting the attributes back in the main object would need both a clear definition for which precise semantics are intended, and a case for why those particular semantics are universally the most important ones. Personally I don't think it's a useful idea given that the information is already available from the existing object.

P4: Seems like a strange idea to me. StorageShareCapacity is logically a part of the StorageShare object, hence the name and indeed the proposal in P3. If a similar object is wanted for Datastore then it should be a new object with a new name. In principle it's possible that one Share could be spread across multiple Datastores so there's no simple relation between them.

Stephen

_______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg

-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin

-- Dr. Alessandro Paolini Operations Officer - EGI Foundation Science Park 140 1098 XG Amsterdam The Netherlands skype: alessandro.paolini.egi ********************************* "I believe in the power of laughter and tears" "as an antidote to hatred and terror" "A day without laughter" "is a wasted day" >>> Charlie Chaplin