US (NVO/VAO) opinions on HTTP GET in VOSpace 2.0
dtody at nrao.edu
Tue Sep 29 13:09:12 PDT 2009
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).
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
> or would they contain a HTTP URL
More information about the vospace