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

[Dave Morris]

On 29/09/09 21:52, Doug Tody wrote:
>
> Well this is an awful lot of trouble to go to just to get a file
> from a storage service using a standard protocol.

Yes, it is isn't it.
If standard HTTP GET works for your data, then please use a webserver.

> In effect what I am suggesting is that we integrate this resolver service directly
> into each vospace implementation.

Why ?
If standard HTTP GET works for your data, then please use a webserver.
VOSpace is intended to handle the cases where HTTP GET isn't suitable.

> A use case
> where this would not work is if we have a vospace integrated into a
> desktop analysis framework and our desktop (e.g. laptop) is operating
> without an Internet connection.

I'm not sure how embedding a VOSpace service into a desktop application 
would work.
Particularly if it didn't have an active Internet connection.
Could you provide more detail for this ?

On the other hand, what we are working on in AstroGrid is implementing a 
VOSpace resolver in the VODesktop client. This will resolve resolve 
vos://... URIs and provide a localhost http://... URL that can be passed 
via SAMP to other desktop applications on the same machine. The 
AstroGrid VODesktop client would handle all of the authentication and 
protocol negotiation and act as a proxy for the other desktop 
applications. This enables us to access secure resources in VOSpace 
using the single sign on provided by our VODesktop client and pass the 
data to other SAMP enabled applications running on the same machine.

> this might mean making HTTP a special case with optimized support.
> I don't like special cases either but this is a pretty important one

If standard HTTP GET works for your data, then please use a webserver.
VOSpace is intended to handle the cases where HTTP GET isn't suitable.

So far you have not convinced me that this special case is special 
enough to justify adding it to the VOSpace specification.

Regards,
Dave