Just because they are orthogonal, there is no association between paths and spaces. Therefore, I was proposing 2 classes, one to describe the spaces with their ACLs and one to describe the namespace with its ACLs, if needed, of course. The space described in which physical pool the file ends up. The namespace describes how logically the files are organized and who has access to them. Flavia Burke, S (Stephen) wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Flavia Donno said: No, just the root. The point is that, as you have heard during the workshop, there might be 2 roots for the same share, like in the PIC case.
OK, we discussed this a bit ... we can clearly do it, but it's likely to make queries significantly more complicated. The suggestion was to come up with an explicit proposal to see what the impact would be. However, I think there's also a question of how common this use case would really be; we've been constantly told that spaces are orthogonal to paths (re-iterated in your MOU addendum proposal!) and yet you're now suggesting we need multiple defined paths within spaces. Does this just mean that something is wrong in the way the SRM is being used? After all, fundamentally SURLs have no real significance, it's the LFN/GUID in the catalogue which really identifies the file.
Stephen