VOSpace 2.1 issues

[Mike Fitzpatrick]

On Fri, Sep 12, 2014 at 6:04 PM, Brian Major <majorb at nrc-cnrc.gc.ca> wrote:

>
> Right, forgot about that.  Does that imply that capabilities should not be
> controlled by users at all then?
>

Not at all, if the user has no control then I'd say the capabilities
concept is much less useful!

The start of all this was in noting that createNode explicitly says
capabilities cannot be set in the call, and a setNode is only used to set
properties of a node, and there is nothing else to explicitly set a
capability once a node has been created.  This means a service can offer a
capability, but it would apply to all nodes or to none at all.  If there
were "special" pre-defined nodes with a capability then the user would
still be at the mercy of whatever options the service allowed (e.g. there'd
be no way to specify a different out name/database/whatever).

In the discussion that started all these we had three capabilities in mind:
 1) an SIA service for all images put into the container, 2) a service that
takes any table and loads it into a database, and 3) a generic "JobRunner"
capability that takes any new file put into the space and runs some
user-defined command on it (as defined in some named command/config file in
the space, obviously on some trusted host).  As it stands there is no way
for a VOSpace to offer these in a list of supported capabilities, but
assign only one of those to a specific container, and no way for the user
to create multiple instances with slightly different parameters.

For something like the SIA service example (one used by the spec as well)
an attachCapabilities method would need to return the service URL the
client could then use.  Similarly one can imagine wanting to set parameters
such as one to force a scan of the current container holdings when building
the service (e.g. when you attach the capability to an existing container)
or to use only new images, to pass in DB login params, etc.  You could
argue these parameters are properties of the node and that setNode would
suffice, but there should probably be a fixed syntax (e.g.
"<capName>.<param>") defined for this.

The idea of a detachCapability is needed in workflows where you might want
to suspend the capability for some reason.



>  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.
>

It's a matter of semantics whether an SIA service is a 'view' of a
container, but I think capabilities and views are fundamentally different.
  It is perfectly reasonable for a container to offer multiple formats to
view a container, the same isn't true for a capability that might process
the data in some way (i.e. in which order are multiple capabilities
executed?).

Cheers,
-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20140912/6747b91a/attachment-0001.html>