Discussion page for the VOSpace 2.1 specificationThis 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. | ||||||||
Changed: | ||||||||
< < | Changes and Enhancements for VOSpace 2.1 | |||||||
> > | Changes and Enhancements for VOSpace 2.1 | |||||||
Changed: | ||||||||
< < | Parameter based sync transfer negotiation | |||||||
> > | Parameter based sync transfer negotiation | |||||||
Changed: | ||||||||
< < | 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"> | ||||||||
Changed: | ||||||||
< < | 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. | |||||||
Changed: | ||||||||
< < | 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. | |||||||
Changed: | ||||||||
< < | 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:
| ||||||||
Changed: | ||||||||
< < | Link Node documentation clarity | |||||||
> > | Notes | |||||||
Changed: | ||||||||
< < | For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.: | |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > | The 2.1 Working Draft | |||||||
Changed: | ||||||||
< < | For future VOSpace versions: | |||||||
> > | ||||||||
Added: | ||||||||
> > |
Change NotesFrom version 2.0-20130329 (in progress):
For future VOSpace versions: | |||||||
<--
|