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

[Douglas Tody]

Hi Matthew -

Well in that case I can't see the issue being seriously addressed
and resolved.  Why the rush anyway since this is still a month away?
We have only discussed this for a day or so, and have thus far only
heard arguments from two of us.

One thing we might do is poll the USVAO team a bit more broadly to see
what others think on our side of the effort.

I leave on travel to the ADASS tomorrow but will be back in contact by
Sunday or thereabouts.

 	- Doug


On Thu, 1 Oct 2009, Matthew Graham wrote:

> Hi,
>
> OK, I'm going to defer further discussion of this option to Garching where 
> the working group will take a considered vote.
>
> 	Cheers,
>
> 	Matthew
> 	On Oct 1, 2009, at 3:52 PM, Dave Morris wrote:
>
>> 
>> 
>> 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
>