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

[Guy Rixon]

On 2 Oct 2009, at 00:19, Douglas Tody wrote:

> Hi Dave -
>
> In few cases currently in actual archives do we use a mere webserver
> to deliver data to users.  With the DAL services currently often it
> is the service itself which delivers the data (services the HTTP GET).
> Very commonly a server is dedicated to these services and there is no
> conventional Web server.

Sure...but from the client's point of view, that dedicated server is a  
web server, even if it's Tomcat rather than Apache httpd.


> In any case, we need VOSpace for per-user
> storage management for asynchronous services, for table integration
> with TAP (where the file is also a DBMS table), and so forth.

I think maybe you need to explain this for those who haven't been  
following the details of the TAP debate.

Dave's position (if I summarize correctly; please amend if not) is  
where the client only reads from the service of origin, then you don't  
need VOSpace. This remains true even when those data are generated by  
an asynchronous request and when they are kept available on the server  
for some time.

I agree with Dave for this case: UWS is a better interface for  
managing those data than VOSpace.

Your position, if I understand correctly, relates to data inbound to  
the TAP service. VOSpace might be useful or necessary for this, but I  
think you need to show a detailed case.

Regards,
Guy

>
> Cheers,
>
> 	- Doug
>
>
> On Thu, 1 Oct 2009, 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
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/vospace/attachments/20091002/b85cf58f/attachment-0001.html>