Hi Stephen, On 07/06/18 12:01, Stephen Burke - UKRI STFC wrote:
glue-wg <glue-wg-bounces@ogf.org> On Behalf Of Paul Millar said:
I have a slight preference for "Paths" over "OtherPaths", since OtherPaths suggests the value of Path is somehow canonical or preferred, which (I believe) isn't the intention.
It's preferred in the sense of being a default, use that path if you don't have a reason to do something else.
I don't really buy that as an argument. Either a StorageShare is writeable from a single path, in which case it is (trivially) the default, or there are multiple paths that could be used. If multiple paths exist then the choice of which one to use is very likely to be domain-specific and not something that is universally true for all users. A (made up) example: the ATLAS Higgs group should default to /data/atlas/higgs and the ATLAS SUSY group should default to /data/atlas/susy, even though writing into either path would consume resources from the same StorageShare (and writing into /data/atlas would consume resources on a different StorageShare). Which path should be advertised as Path: /data/atlas/higgs or /data/atlas/susy ?
That's how lcg-utils always worked, if you just specified a file name rather than a full path the code would write it to the default path.
Perhaps, however I find this a poor argument -- lcg-utils is dead.
If there's only one default that's unambiguous, if you have several it's not clear what the semantics should be and anyway it's a change. Lcg-utils is now deprecated in favour of gfal
Not just deprecated, lcg-utils is no longer supported (== dead) and has been for years.
and [gfal] doesn't use the information system, it just leaves it to the user,
Exactly. The concept of a "default path" is broken, which is why gfal doesn't support it.
but that still gives the user the same question of how they construct a path if they don't have other knowledge.
I think only the user (or, by extension, the VO) can know into which path they should write their data. Cheers, Paul.