International Virtual Observatory Alliance

Difference: VOSpace21Spec (8 vs. 9)

Revision 92014-05-07 - BrianMajor

META TOPICPARENT	name="VOSpaceHome"

VOSpace home page

Discussion page for the VOSpace 2.1 specification

This is a discussion page for the VOSpace-2.1 service specification.

Please edit this page directly to add comments or specification changes and additions.

Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification.

Changes and Enhancements for VOSpace 2.1

Parameter based sync transfer negotiation

This is a proposal to support the ability to perform a transfer negotiation by posting transfer parameters to the /sync endpoint. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example:

Parameter based POST:

curl -X POST -d "TARGET=vos://nvo.caltech!vospace/mydata1&DIRECTION=pullFromVoSpace&PROTOCOL=ivo://ivoa.net/vospace/core#httpget" "http://localhost:8000/sync"

Would be equivalent to:

curl -X POST -d @job.xml "http://localhost:8000/sync"

Where job.xml is a file containing:

<vos:transfer xmlns:vos="http://www.ivoa.net/xml/VOSpace/v2.1"> <vos:target>vos://nvo.caltech!vospace/mydata1</vos:target> <vos:direction>pullFromVoSpace</vos:direction> <vos:protocol>ivo://ivoa.net/vospace/core#httpget</vos:protocol> </vos:transfer>

The motivation for adding this functionality is to allow the negotiation of a transfer to happen with a single URL without having a smart client or having to generate an XML document. This is convenient when referring to VOSpace nodes from web interfaces.

Add desired authentication method to transfer document

There isn't enough information in the transfer negotiation document to produce URLs to the data store correctly. The missing piece of information is authentication method they wish to use on the URLs. For example, if they wish to use userid/password to authenticate, the URLs must be pointed at a resource that will block and collect that information. If a cookie is to be used, the resource must not block. Authentication method options should include:

anonymous
userid/password basic authentication
cookies
x509 client certificate

This field should be optional in the transfer document.

Added:

>
> Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008).

Link Node documentation clarity

Changed:

<
< For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.

>
> For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.:

Changed:

<
<

Issues

>
>

Example, on the getNode operation, what does view=data mean when the target is a link node? Is it a 'ViewNotSupported' fault or should the link target be resolved and downloaded?

Added:

>
>

For future VOSpace versions:

In the transfer object, the 'direction' can conflict with the protocol URI. For example, the direction can be 'pullFromVoSpace' and the protocol can be 'HTTP-PUT'. This could be cleaned up to remove error cases.
Should VOSpace should have it's own registry extension, VoSpaceRegEx?

<-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

View topic | History: r22 < r21 < r20 < r19 | More topic actions...