US (NVO/VAO) opinions on HTTP GET in VOSpace 2.0

[Matthew Graham]

Hi,

A few weeks back I solicited the NVO Technical WG for their thoughts  
on the HTTP GET issue.

To recap, the proposal is to have a simple HTTP GET to retrieve a  
file, expressed in a single URL:

http://nvo.caltech.edu/vospace/mydata/table1?view=ivo://net.ivoa/views/votable-1.1

without the transfer negotiation that the VOSpace spec currently  
requires (the negotiation will remain but this provides a user- 
friendly shortcut).

In the absence of the simple HTTP GET, the client will POST a Transfer  
representation saying which node they want to get and what protocol  
they are using to http://nvo.caltech.edu/vospace/transfers and then  
will be get back details of the HTTP GET endpoint to use.

This seems great but to illustrate some concerns, consider the user  
who wants to implement VOSpace solely for big data transfers, say  
using GridFTP, they would still have to implement this HTTP GET if it  
is a mandatory part of the spec but might not support HTTP as a  
transport protocol otherwise. There is also the issue that VOSpace 1.x  
was specifically defined as transport protocol agnostic and we are now  
breaking that.

The overwhelming opinion from the US is in favour of the simple HTTP  
GET, mainly on the basis that this particular piece of functionality  
will drive >90% of usage (probably 99%). It is less clear, however,  
whether this non-negotiated HTTP GET support should be mandatory for  
all VOSpace 2.0 services or optional. Since VOSpace 2.0 is inherently  
HTTP-based (being RESTful), adding a mandatory HTTP-based transfer  
route does  not seem to require much more implementation.

	Cheers,
	
	Matthew





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/vospace/attachments/20090928/1c2a3de5/attachment-0001.html>