VOSpace 2.1 issues

[Brian Major]

On Fri, Sep 12, 2014 at 2:18 PM, Matthew Graham <mjg at cacr.caltech.edu>
wrote:

> Hi Brian,
>
> On Sep 12, 2014, at 12:59 PM, Brian Major wrote:
>
> 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...
>
>
>
> The spec specifically says that you cannot use node creation to set the
> capabilities on a given node so there is actually no way to do this. You
> either get all the capabilities that a server offers on all nodes or none -
> the user has no control over this.
>

Right, forgot about that.  Does that imply that capabilities should not be
controlled by users at all then?  Maybe the concept of capabilities isn't
right at the node level.  Would views allow for the kind of use cases
you're considering?  (assuming your second original point is addressed)
 Creating a node would bring with it the views that are accepted and
provided by the node type.

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