International Virtual Observatory Alliance

Difference: VOSpace21Spec (11 vs. 12)

Revision 122014-05-09 - 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.
- META TOPICPARENT
+  name="VOSpaceHome"
-<
<
+ Changes and Enhancements for VOSpace 2.1
->
>
+ Changes and Enhancements for VOSpace 2.1
-<
<
+ Parameter based sync transfer negotiation
->
>
+ Parameter based sync transfer negotiation
-<
<
+This is a proposal to support the ability to perform a transfer negotiation by performing an HTTP GET with transfer parameters to the /sync endpoint.  For example:
->
>
+This is a proposal to support the ability to perform a transfer negotiation by performing an HTTP GET with transfer parameters to the /sync endpoint. For example:
 Parameter based GET:

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

Would be somewhat 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 reduce the number of redirects the client needs to perform before starting the data transfer.  The HTTP GET request would return the endpoint URL for data transfer immediately.  The POST to the /sync returns a redirect to the transfer details of the job, which contains the endpoint URL.
->
>
+The motivation for adding this functionality is to reduce the number of redirects the client needs to perform before starting the data transfer. The HTTP GET request would return the endpoint URL for data transfer immediately. The POST to the /sync returns a redirect to the transfer details of the job, which contains the endpoint URL.
-<
<
+Since there is no job associated with the optimized GET, there less ability to do correct error handling.  Upon error, clients should revert to the POST to /sync for full transfer negotiation and error handling capability.  This is an optimistic approach and assumes that there is a low error rate in the service and this fallback would not happen frequently.
->
>
+Since there is no job associated with the optimized GET, there less ability to do correct error handling. Upon error, clients should revert to the POST to /sync for full transfer negotiation and error handling capability. This is an optimistic approach and assumes that there is a low error rate in the service and this fallback would not happen frequently.
-<
<
+ Add desired authentication method to transfer document
->
>
+ 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.

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
->
>
+ Notes
-<
<
+For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.:
->
>
+ Add authentication types to the capabilities?
-<
<
+ 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?
->
>
+ The 2.1 Working Draft
-<
<
+ For future VOSpace versions:
->
>
->
>
+ Change Notes 

From version 2.0-20130329 (in progress):
 

 Addition of optimized HTTP GET method of data transfer for pushToVoSpace, pullFromVoSpace
  Addition of authType to Protocol in XML schema for transfer negotiation.
  Added preliminary list of standard authType URIs
  Removed view=data convenience method of data transfer
  Corrections to minor XML format errors in the examples throughout the document.
 

Changes in detail: 

 (3.4.3) Added "view parameters" to view description
  (3.5, Appendix B) Corrections to required, optional protocol parameters
  (Appendix A) Addition of authType element to protocol element
  (3.6.2) Added sentence about the protocol authType
  (3.8) Added paragraph about HTTP GET to /sync endpoint for optimized transfer negotiation
  (4) Added paragraph about the (preliminary) set of supported authentication types
  (5.4.1, 5.4.2, 5.4.3, 5.4.4) XML formatting corrections in examples
  (5.4.3.1) Removed view=data as a suggested convenience for "pullFromVoSpace".  Replaced with optimized HTTP GET from /sync example.
  (5.4.1, 5.4.3) Added authType to protocol in the examples
  (3.5.3) Added (preliminary) set of standard authType URIs
  (6) Preliminary change notes
 

 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?
  Section 4, Access Control: Version 3.0 should state access control policies at the Node level.
 
<-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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