<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 12, 2014 at 6:04 PM, Brian Major <span dir="ltr">&lt;<a href="mailto:majorb@nrc-cnrc.gc.ca" target="_blank">majorb@nrc-cnrc.gc.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div><br></div></div></div><div>Right, forgot about that.  Does that imply that capabilities should not be controlled by users at all then? </div></div></div></div></blockquote><div><br></div><div>Not at all, if the user has no control then I&#39;d say the capabilities concept is much less useful! </div><div><br></div><div>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 &quot;special&quot; pre-defined nodes with a capability then the user would still be at the mercy of whatever options the service allowed (e.g. there&#39;d be no way to specify a different out name/database/whatever).</div><div><br></div><div>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 &quot;JobRunner&quot; 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.</div><div><br></div><div>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. &quot;&lt;capName&gt;.&lt;param&gt;&quot;) defined for this.  </div><div><br></div><div>The idea of a detachCapability is needed in workflows where you might want to suspend the capability for some reason.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> Maybe the concept of capabilities isn&#39;t right at the node level.  Would views allow for the kind of use cases you&#39;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.</div></div></div></div></blockquote><div><br></div><div>It&#39;s a matter of semantics whether an SIA service is a &#39;view&#39; 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&#39;t true for a capability that might process the data in some way (i.e. in which order are multiple capabilities executed?).</div><div><br></div><div>Cheers,</div><div>-Mike</div><div><br></div><div><br></div></div><br></div></div>