<div dir="ltr">Hi Matthew, thanks for the note. Some questions/comments below...<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 10:39 AM, Matthew Graham <span dir="ltr"><<a href="mailto:mjg@cacr.caltech.edu" target="_blank">mjg@cacr.caltech.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
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:<br>
<br>
(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.<br></blockquote><div><br></div><div>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...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So, perhaps it is a good approach to tie the capabilities and views to UWS more explicitly?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
Cheers,<br>
<br>
Matthew</blockquote></div><br>Brian<br clear="all"><div><br></div>
</div></div>