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

[Guy Rixon]

Doug,

sound to me like you're looking for this feature set:

- "management" (details TBD) of uploaded to TAP, those data to persist  
between queries, but to be private to one user;

- a naming scheme for said data;

- an HTTP URL to retrieve each uploaded data-set.

Why is this VOSpace? Why is it not just another aspect of TAP? If the  
answer is that the user already has a VOSpace client, then fine, I  
like that approach, but in that case the user already has a client  
that can do the protocol negotiation. If the user has to write or  
obtain a special client, then there's no compulsion to use VOSpace.

Guy


On 2 Oct 2009, at 00:56, Douglas Tody wrote:

> Hi Dave -
>
> Well the point of this of course was that we do need VOSpace for this
> sort of thing, even when we do not require advanced high performance
> transport protocols (which we want, just not most of the time).
> So a mere Web server is not a sufficient alternative.  Having a simple
> HTTP GET available easily for common read access is very attractive.
>
> Also I am not sure yet that VOSpace and TAP will actually work well
> together.  Probably mostly so, but we will need a more careful look
> at this and probably prototyping to be sure.  The basic idea is that
> when we upload tables as files to the VOSpace we keep the byte-stream
> file, but also autoload the table into a DBMS table.  Clearly this
> will work but there are issues with table naming, datatypes, etc. to
> be considered.
>
> 	- Doug
>
>
> On Fri, 2 Oct 2009, Dave Morris wrote:
>
>> On 02/10/09 00:34, Douglas Tody wrote:
>>> What about basic authenticated, resource controlled, per-user  
>>> network
>>> storage? Or table integration via TAP? Can these be supported as  
>>> well?
>>
>> Yep.
>> VOSpace 1.5 should already be capable of handling these.
>> VOSpace 2.0 was just meant to be a simple update from SOAP to REST.
>>
>> If anyone has use cases for authenticated, resource controlled, per- 
>> user network storage or database table integration that can't be  
>> handled by the VOSpace 1.5 SOAP service or the proposed VOSpace 2.0  
>> REST service then please let us know.
>>
>> Dave
>>