Proposals for VOSpace Recommendation

[Zorba, Sonia]

Dear all,
during the last Interoperability Meeting I presented some issues that me
and my colleagues encountered in implementing a VOSpace service following
the recommendation document. Since the limits that we found could lead to
the definition of a new version of the specification it has been suggested
to open a thread in this mailing list, to discuss them with the whole
community.

We are proposing several points, so I'll number them.

1. Add a standard property to indicate that node metadata can be edited
(e.g. groupread property can be changed), but the node can't be deleted or
moved. Suggested names: locked or sticky

2. Add a standard property to indicate that a data node doesn't contain its
data yet (so data has to be retrieved using a pullToVoSpace operation
before being able to download the data using a pullFromVoSpace).

3. Allow to specify multiple target nodes (instead of exactly one target
node) for transfer operations. This is useful if the user desires to select
a subset of files inside a folder instead of the whole folder.

4. Add a mechanism to update certain metadata recursively on all child
nodes. It is particularly useful for setting groupread and groupwrite
properties.

5. If the previous point will be added to the recommendation, it could be
useful to specify also how a recursive group update should behave. Suppose
for example to have a parent node having groupread="group1" and a child
node having groupread="group2". If the user wants to add group3
recursively, a simple recursive setNode would set "group1,group3" on all
the nodes (like a chgrp -R command would do). However, from a user
perspective, maybe it would be preferable to have "group1,group3" on the
parent node and "group2,group3" on the child node (so the operation would
be smart enough to consider the addition or deletion of groups, instead of
a plain set).

6. Clarify what to use as folder size (should it be the total size of its
content?)

7. On the getNode endpoint add parameters to perform paginated requests.
Useful for nodes having too many children.

8. Clarify how to define a custom delimiter for properties having multiple
values. Recommendation says «When a Property can take multiple values,
e.g., a list of groups which can access a particular resource, these SHOULD
be comma-separated, unless the property description defines a specific
delimiter.», however property description is a free text field and it could
be hard to parse the custom delimiter value from it using automatic tools.

Thanks for your feedback!

Cheers,
Sonia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20210611/dc53d465/attachment.html>