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

[Doug Tody]

Hi Dave -

I meant a HTTP URL, although in principle a VOSpace URL could be
possible as well.  But for maximum flexibility and to avoid requiring
VOSpace-specific capabilities on the client side HTTP would be required
(hence simple clients, tools like wget/curl etc. could be used for
retrieval even if the service stores the dataset in a local VOSpace).

 	- Doug


On Tue, 29 Sep 2009, Dave Morris wrote:

> On 29/09/09 04:33, Douglas Tody wrote:
>>
>>  Just to amplify on the discussion Matthew recounts, here is what I
>>  originally argued when we discussed this within NVO (this all still
>>  seems valid):
>> 
>> >  I should think there would be any number of cases where this simple
>> >  file retrieval method would be useful for files stored in a VOSpace.
>> >  The most obvious motivation is to allow a VOSpace to behave (in the
>> >  case of simple read-only file retrieval) like the HTTP GET-based file
>> >  storage mechanisms currently in wide use within VO.
>> > 
>> >  This would allow any acref-based DAL service for example to integrate a
>> >  colocated VOSpace but still use the acref mechanism to refer to files
>> >  and allow simple clients to retrieve them. Hence a SIA query could
>> >  use acrefs to point into a local VOSpace. Or a future async SIA which
>> >  generates images asynchronously and stores them in a VOSpace could
>> >  provide an acref to the client to be used for retrieval. In some
>> >  scenarios this acref might be precomputed before generating storing
>> >  the image, i.e., might reference virtual data yet to be generated
>> >  and stored in the VOSpace.
>> > 
>> >  I would not be surprised if >90% [probably >99%] of file retrievals from
>> >  a VOSpace in the future would be of this type.
>
> Could you give a specific example as to what URI or URL the SIA acrefs would 
> contain in your scenario ?
> Would they contain a VOSpace URI
>
> 	vos://service/path/file
>
> or would they contain a HTTP URL
>
> 	http://service/path/file
>
> Thanks,
> Dave
>