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

[Doug Tody]

Hi Dave -

A typical use case would be to integrate VOSpace into a DAL service.
So we execute a SIAP image generation task asynchronously and it puts
the generated image (possibly many of them) in a colocated VOSpace.
We want the client to be able to GET the generated image using our
existing mechanisms.  The natural thing to do would be for the SIAP
service, when it puts the image in the vospace, to ask the vospace
for an access reference URL to the stored data and this URL would
be what we give back to the client as the acref.

In this case another option would be to have the SIAP service handle
the HTTP GET and talk to the vospace on the back end, similar to your
proxy scenario.  However if the vospace is the storage manager it
seems cleaner and more scalable to have it serve the data directly
to the client.

 	- Doug



On Tue, 29 Sep 2009, Dave Morris wrote:

>
> On 29/09/09 04:33, Douglas Tody wrote:
>> 
>> >  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.
>
> In that case, why not just use a webserver ?
> If you are serving data from a public archive using unauthenticated HTTP GET, 
> then why not just store the data in a normal web server and pass standard 
> HTTP URLs to the client.
> You don't need VOSpace for this use case, so I don't see a need to modify 
> VOSpace to support it.
>
> Regards,
> Dave
>
>