VOSpace 2.1 issues

[Brian Major]

Hi Matthew, thanks for the note.  Some questions/comments below...

On Thu, Sep 11, 2014 at 10:39 AM, Matthew Graham <mjg at cacr.caltech.edu>
wrote:

> Hi,
>
> Mike Fitzpatrick and I were reviewing the VOSpace spec last week
> specifically for capability stuff and realized that there are a couple of
> elements missing that we would like to see included in VOSpace 2.1:
>
> (1) At the moment you get all-or-none with the capabilities on a node
> whereas there should be a way to specify which capabilities you would like
> on a node so we would like to propose two additional methods to work a
> specific node: attachCapability and detachCapability.
>

I'm probably not correctly understanding these proposed methods: are you
suggesting that clients should have the ability to modify the capabilities
of a node?  Couldn't the desired capabilities be set by creating a new
node?  I think it would be tricky to accept capability modification actions
when there is potentially data already associated with the node...


>
> (2) There is also no specific route for an error in a capability execution
> to be reported back to a user. For example, suppose a node has the
> capability that a VOTable uploaded to it will automatically be converted
> into a database table somewhere. In theory, the data transfer should
> complete only when the capability has successfully executed rather than
> just when the byte transfer component has completed. However, if there is
> an issue with converting the VOTable to a database table then the transfer
> should indicate that it failed but with what error message? Internal server
> issue? We would like there to be an additional error message for capability
> issues.
>

This I totally agree with, and the same argument can be made for node views
I think.  There is a disconnect in the workflow from the discovery and
execution of node behaviour to the completion of the work.  Transfers in
VOSpace benefit from the asynchronous support of UWS (including error
reporting), but there isn't a defined route between node capabilities and
views to the UWS lifecycle.

For this reason, the CADC implementation of VOSpace view requests result in
redirects to the analogous transfer when applicable.  (This can be
accomplished in v2.1 now with the support of parameter-based transfer
negotiations.)  However, this only works with synchronous requests.  As the
spec stands, clients wouldn't know how to deal with UWS for any type of
asynchronous action, which I believe is your point.  If there was UWS
support for capabilities, the supporting software (in your example, the
code that converts VOTable to database entires) could update the job with
success or failure information when complete.

So, perhaps it is a good approach to tie the capabilities and views to UWS
more explicitly?


>
> Really, it is quite surprising that these have not been thought of before
> but maybe now is when we are beginning to think about the capability
> aspects of the spec properly for the first time.
>
>         Cheers,
>
>         Matthew


Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20140912/1ca8da26/attachment.html>