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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis is a proposal to support the ability to perform a simplified transfer negotiation by executing 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">
Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects.
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 documentIn certain cases, 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, but are not limited to:
Capabilities: dynamic capabilities and error handlingPlease refer to this threadAddressing changes from VOSpace 2.1Please refer to this page Dave Morris has identified a number of inconsistencies in the document, most dating back to the v1.1 -> v2.0 conversion. There is the question as to how these should be addressed, considering VOSpace 2.0 has been a proposed recommendation for some time. Here are three options:
New document formatThe existing document is in html format and needs to be converted to a more editable medium. Should this be XHTML or ivotex?VOSpace interoperable clients and serversI would like to propose the goal of having a working interoperability of two or more VOSpace implementations (version 2.1?) by Oct 2015. Please update the implementations table on the VOSpace home page if your institution has built a VOSpace.VOSpace 2.1 - Two Implementations | ||||||||
Changed: | ||||||||
< < | Two implementations of the VOSpace 2.1 specification needed by June, 2015. | |||||||
> > | Two implementations of the VOSpace 2.1 specification needed in the beginning of 2015 (March/April will be nice) to push the document to the PR Status if we find a consensus during the Banff interop. | |||||||
The 2.1 Working Draft
Change NotesFrom version 2.0-20130329 (in progress):
For future VOSpace versions:Please see The VOSpace 3.0 Discussion Page for future changes and enhancements to VOSpace beyond version 2.1.<--
|
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis is a proposal to support the ability to perform a simplified transfer negotiation by executing 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">
Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects.
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 documentIn certain cases, 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, but are not limited to:
Capabilities: dynamic capabilities and error handlingPlease refer to this threadAddressing changes from VOSpace 2.1Please refer to this page Dave Morris has identified a number of inconsistencies in the document, most dating back to the v1.1 -> v2.0 conversion. There is the question as to how these should be addressed, considering VOSpace 2.0 has been a proposed recommendation for some time. Here are three options:
New document formatThe existing document is in html format and needs to be converted to a more editable medium. Should this be XHTML or ivotex?VOSpace interoperable clients and serversI would like to propose the goal of having a working interoperability of two or more VOSpace implementations (version 2.1?) by Oct 2015. Please update the implementations table on the VOSpace home page if your institution has built a VOSpace. | ||||||||
Added: | ||||||||
> > |
VOSpace 2.1 - Two ImplementationsTwo implementations of the VOSpace 2.1 specification needed by June, 2015. | |||||||
The 2.1 Working Draft
Change NotesFrom version 2.0-20130329 (in progress):
For future VOSpace versions:Please see The VOSpace 3.0 Discussion Page for future changes and enhancements to VOSpace beyond version 2.1.<--
|
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis is a proposal to support the ability to perform a simplified transfer negotiation by executing 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">
Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects.
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 documentIn certain cases, 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, but are not limited to:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Capabilities: dynamic capabilities and error handlingPlease refer to this threadAddressing changes from VOSpace 2.1Please refer to this page Dave Morris has identified a number of inconsistencies in the document, most dating back to the v1.1 -> v2.0 conversion. There is the question as to how these should be addressed, considering VOSpace 2.0 has been a proposed recommendation for some time. Here are three options:
New document formatThe existing document is in html format and needs to be converted to a more editable medium. Should this be XHTML or ivotex?VOSpace interoperable clients and serversI would like to propose the goal of having a working interoperability of two or more VOSpace implementations (version 2.1?) by Oct 2015. Please update the implementations table on the VOSpace home page if your institution has built a VOSpace. | ||||||||
Deleted: | ||||||||
< < |
Notes / Questions / Discussion Items / Ideas
| |||||||
The 2.1 Working Draft
Change NotesFrom version 2.0-20130329 (in progress):
For future VOSpace versions:Please see The VOSpace 3.0 Discussion Page for future changes and enhancements to VOSpace beyond version 2.1.<--
|
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. | ||||||||
Deleted: | ||||||||
< < | Since this is a minor revision, all changes must be backwards compatible with the VOSpace-2.0 specification. | |||||||
Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis is a proposal to support the ability to perform a simplified transfer negotiation by executing 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">
Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects.
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 documentIn certain cases, 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, but are not limited to:
| ||||||||
Changed: | ||||||||
< < | This field should be optional in the transfer document. | |||||||
> > |
| |||||||
Added: | ||||||||
> > | This field is optional in the transfer document. | |||||||
Changed: | ||||||||
< < | Update: The IVOA Single Sign-On Profile should be consulted on this, though it is now a bit out-of-date (2008). | |||||||
> > | Capabilities: dynamic capabilities and error handling | |||||||
Changed: | ||||||||
< < | Notes / Questions / Discussion Items | |||||||
> > | Please refer to this thread | |||||||
Added: | ||||||||
> > | Addressing changes from VOSpace 2.1Please refer to this page Dave Morris has identified a number of inconsistencies in the document, most dating back to the v1.1 -> v2.0 conversion. There is the question as to how these should be addressed, considering VOSpace 2.0 has been a proposed recommendation for some time. Here are three options:
New document formatThe existing document is in html format and needs to be converted to a more editable medium. Should this be XHTML or ivotex?VOSpace interoperable clients and serversI would like to propose the goal of having a working interoperability of two or more VOSpace implementations (version 2.1?) by Oct 2015. Please update the implementations table on the VOSpace home page if your institution has built a VOSpace.Notes / Questions / Discussion Items / Ideas | |||||||
| ||||||||
Deleted: | ||||||||
< < |
| |||||||
The 2.1 Working Draft | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Change NotesFrom version 2.0-20130329 (in progress):
For future VOSpace versions: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > | Please see The VOSpace 3.0 Discussion Page for future changes and enhancements to VOSpace beyond version 2.1. | |||||||
Deleted: | ||||||||
< < |
| |||||||
<--
|
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis is a proposal to support the ability to perform a simplified transfer negotiation by executing 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">
Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects.
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 documentIn certain cases, 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, but are not limited to:
Notes / Questions / Discussion Items
The 2.1 Working Draft
Change NotesFrom version 2.0-20130329 (in progress):
For future VOSpace versions:
<--
| ||||||||
Deleted: | ||||||||
< < |
| |||||||
| ||||||||
Deleted: | ||||||||
< < |
| |||||||
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis is a proposal to support the ability to perform a simplified transfer negotiation by executing 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">
Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects.
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 documentIn certain cases, 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, but are not limited to:
Notes / Questions / Discussion Items
The 2.1 Working Draft
Change NotesFrom version 2.0-20130329 (in progress):
For future VOSpace versions:
<--
| |||||||||
Added: | |||||||||
> > |
| ||||||||
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis is a proposal to support the ability to perform a simplified transfer negotiation by executing 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">
Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects.
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 documentIn certain cases, 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, but are not limited to:
Notes / Questions / Discussion Items
The 2.1 Working Draft
Change NotesFrom version 2.0-20130329 (in progress):
For future VOSpace versions:
<--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
|
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis is a proposal to support the ability to perform a simplified transfer negotiation by executing 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">
Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects.
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 documentIn certain cases, 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, but are not limited to:
Notes / Questions / Discussion Items
The 2.1 Working Draft
Change NotesFrom version 2.0-20130329 (in progress):
For future VOSpace versions:
<--
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
|
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis is a proposal to support the ability to perform a simplified transfer negotiation by executing 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: | ||||||||
< < | Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects. | |||||||
> > | Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects. | |||||||
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 documentIn certain cases, 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, but are not limited to:
| ||||||||
Deleted: | ||||||||
< < | ||||||||
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).
Notes / Questions / Discussion Items
The 2.1 Working Draft | ||||||||
Added: | ||||||||
> > |
| |||||||
Change NotesFrom version 2.0-20130329 (in progress):
| ||||||||
Deleted: | ||||||||
< < | ||||||||
Changes in detail:
For future VOSpace versions:
<--
| ||||||||
Deleted: | ||||||||
< < |
| |||||||
|
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.Changes and Enhancements for VOSpace 2.1Parameter 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 simplified transfer negotiation by executing 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. | |||||||
> > | Instead of returning a redirect to the transferDetails (which will contain the endpoint URL(s)), it would return a single, preferred endpoint URL directly. This is an optimization that reduces the number of redirects. | |||||||
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 | ||||||||
Changed: | ||||||||
< < | 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: | |||||||
> > | In certain cases, 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, but are not limited to: | |||||||
| ||||||||
Added: | ||||||||
> > | ||||||||
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). | ||||||||
Changed: | ||||||||
< < | Notes | |||||||
> > | Notes / Questions / Discussion Items | |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
The 2.1 Working Draft | ||||||||
Deleted: | ||||||||
< < | ||||||||
Change NotesFrom version 2.0-20130329 (in progress):
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
For future VOSpace versions:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
<--
| ||||||||
Added: | ||||||||
> > |
| |||||||
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: | |||||||
<--
|
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.Changes and Enhancements for VOSpace 2.1Parameter 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. This would be functionally equivalent to posting the transfer XML document 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: | ||||||||
Changed: | ||||||||
< < | curl -X POST -d "TARGET=vos://nvo.caltech!vospace/mydata1&DIRECTION=pullFromVoSpace&PROTOCOL=ivo://ivoa.net/vospace/core#httpget" "http://localhost:8000/sync" | |||||||
> > | curl -d "TARGET=vos://nvo.caltech!vospace/mydata1&DIRECTION=pullFromVoSpace&PROTOCOL=ivo://ivoa.net/vospace/core#httpget" "http://localhost:8000/sync" | |||||||
Changed: | ||||||||
< < | Would be equivalent to: | |||||||
> > | 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 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. | |||||||
Added: | ||||||||
> > | 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 documentThere 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:
Link Node documentation clarityFor the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.:
For future VOSpace versions:
| ||||||||
Added: | ||||||||
> > |
| |||||||
<--
|
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiation | ||||||||
Changed: | ||||||||
< < | 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: | |||||||
> > | 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. This would be functionally equivalent to posting the transfer XML document to the /sync endpoint. For example: | |||||||
Changed: | ||||||||
< < | Parameter based POST: | |||||||
> > | Parameter based GET: | |||||||
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"> | ||||||||
Changed: | ||||||||
< < | 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. | |||||||
> > | The motivation for adding this functionality is to reduce the number of redirects the client needs to perform before starting the data transfer. | |||||||
Add desired authentication method to transfer documentThere 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:
Link Node documentation clarityFor the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
For future VOSpace versions: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis 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">
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 documentThere 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:
| ||||||||
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 | |||||||
> > |
| |||||||
Added: | ||||||||
> > | For future VOSpace versions:
| |||||||
<--
|
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis 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">
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 documentThere 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:
Link Node documentation clarityFor the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.Issues | ||||||||
Deleted: | ||||||||
< < | Parameters for views in negotiated transfers?One of the elements in a transfer document is the "view" element. If a value for this view is supplied (and it is not the Default View), VOSpace will respond in a way that is specific to that view for the target Node. However, one can imagine views that require input parameters in order to create a sensible response. For example: cutouts. For a cutout view to be implemented, there must be a way for users to provide cutout parameters. Version 2.0 of VOSpace does not allow for input parameters to be supplied to views in transfer negotiations. | |||||||
<--
|
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis 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">
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 | ||||||||
Changed: | ||||||||
< < | 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: | |||||||
> > | 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: | |||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Deleted: | ||||||||
< < | ||||||||
This field should be optional in the transfer document.
Link Node documentation clarityFor the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.IssuesParameters for views in negotiated transfers?One of the elements in a transfer document is the "view" element. If a value for this view is supplied (and it is not the Default View), VOSpace will respond in a way that is specific to that view for the target Node. However, one can imagine views that require input parameters in order to create a sensible response. For example: cutouts. For a cutout view to be implemented, there must be a way for users to provide cutout parameters. Version 2.0 of VOSpace does not allow for input parameters to be supplied to views in transfer negotiations.<--
|
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis 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">
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. | ||||||||
Added: | ||||||||
> > |
Add desired authentication method to transfer documentThere 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:
| |||||||
Link Node documentation clarityFor the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.IssuesParameters for views in negotiated transfers?One of the elements in a transfer document is the "view" element. If a value for this view is supplied (and it is not the Default View), VOSpace will respond in a way that is specific to that view for the target Node. However, one can imagine views that require input parameters in order to create a sensible response. For example: cutouts. For a cutout view to be implemented, there must be a way for users to provide cutout parameters. Version 2.0 of VOSpace does not allow for input parameters to be supplied to views in transfer negotiations.<--
|
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.Changes and Enhancements for VOSpace 2.1Parameter based sync transfer negotiationThis 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">
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.
Link Node documentation clarityFor the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes. | ||||||||
Added: | ||||||||
> > |
IssuesParameters for views in negotiated transfers?One of the elements in a transfer document is the "view" element. If a value for this view is supplied (and it is not the Default View), VOSpace will respond in a way that is specific to that view for the target Node. However, one can imagine views that require input parameters in order to create a sensible response. For example: cutouts. For a cutout view to be implemented, there must be a way for users to provide cutout parameters. Version 2.0 of VOSpace does not allow for input parameters to be supplied to views in transfer negotiations. | |||||||
<--
|
Discussion page for the VOSpace 2.1 specificationThis is a discussion page for the VOSpace-2.1 service specification. | ||||||||
Changed: | ||||||||
< < | ||||||||
> > | Please edit this page directly to add comments or specification changes and additions. | |||||||
Changed: | ||||||||
< < | Since this is a minor revision, all changes to the specification must be backwards compatible with the VOSpace-2.0 specification. | |||||||
> > | 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 | |||||||
Deleted: | ||||||||
< < |
Enhancements for VOSpace 2.1 | |||||||
Parameter based sync transfer negotiationThis 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">
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.
Link Node documentation clarityFor the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes.<--
|
Discussion page for the VOSpace 2.1 specificationThis is a discussion page for the VOSpace-2.1 service specification.Since this is a minor revision, all changes to the specification must be backwards compatible with the VOSpace-2.0 specification. | ||||||||
Changed: | ||||||||
< < | Matters arising from IVOA Waikoloa (September 2013) | |||||||
> > | Enhancements for VOSpace 2.1 | |||||||
Parameter based sync transfer negotiationThis 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: | ||||||||
Changed: | ||||||||
< < | <vos:transfer xmlns:vos="http://www.ivoa.net/xml/VOSpace/v2.1"> | |||||||
> > | <vos:transfer xmlns:vos="http://www.ivoa.net/xml/VOSpace/v2.1"> | |||||||
Changed: | ||||||||
< < | The motivation for adding this behaviour 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. | |||||||
> > | 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. | |||||||
Deleted: | ||||||||
< < | Deprecation of view=data | |||||||
Link Node documentation clarity | ||||||||
Added: | ||||||||
> > | For the benefit of implementers, clarify the expected behaviour of the operations in Section 5 when the operation can pertain to LinkNodes. | |||||||
<--
|
Discussion page for the VOSpace 2.1 specificationThis is a discussion page for the VOSpace-2.1 service specification.Since this is a minor revision, all changes to the specification must be backwards compatible with the VOSpace-2.0 specification. Matters arising from IVOA Waikoloa (September 2013)Parameter based sync transfer negotiationThis 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: | ||||||||
Changed: | ||||||||
< < | <vos:transfer xmlns:vos="http://www.ivoa.net/xml/VOSpace/v2.1"> | |||||||
> > | <vos:transfer xmlns:vos="http://www.ivoa.net/xml/VOSpace/v2.1"> | |||||||
Added: | ||||||||
> > | The motivation for adding this behaviour 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. | |||||||
Deprecation of view=dataLink Node documentation clarity<--
|
Discussion page for the VOSpace 2.1 specificationThis is a discussion page for the VOSpace-2.1 service specification.Since this is a minor revision, all changes to the specification must be backwards compatible with the VOSpace-2.0 specification. Matters arising from IVOA Waikoloa (September 2013)Parameter based sync transfer negotiationThis 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">
Deprecation of view=dataLink Node documentation clarity<--
|