VOSpace vs WebDAV

[Dave Morris]

On 2014-05-15 13:20, Markus Demleitner wrote:
> 
> .... and frankly I think plain HTTP
> (in the sense of "curl is all you need") just won't do as a Registry
> client protocol, even with accept: and all the other fancy stuff.
> 

Actually ... Norman's description of the ARK service got me thinking.
I agree with Paul, Norman is probably right about many things and we 
should listen to him more often ;-)

For a registry resolver service, all we want it to do is to resolve an 
'ivo://' URI into the corresponding VOResource document.

So, could we define a 'RegistryResolver' service as a web server where 
you add an 'ivo://' URI to the RegistryResolver endpoint, and you get 
back the corresponding VOResource document, or a 404 error.

Nothing more than that.
No resource discovery.
No query language, table formats or schema.
No partial fragments or subsections of the document.

Just the VOResource XML or a 404 error.

----------------

That would simplify the resolving of 'vos://' URIs into service 
endpoints. Just take everything between 'vos://' and the first '!' and 
send it to your favourite RegistryResolver service.

The RegistryResolver would return the VOResource registration for the 
service.

The VOResource registration would list the service capabilities, one of 
which may be a VOSpace service with all of the protocol negotiation 
stuff.

However, there is nothing in the specification that says that the 
VOResource registration pointed to by a 'vos://' URI should only provide 
a VOSpace service as a capability. In fact, the specification doesn't 
say anything about what capabilities the VOResource should contain. As 
written the VOSpace specification _assumes_ it has at least one VOSpace 
capability, but it doesn't explicitly state that.

In which case, it would be perfectly legit for the VOResource 
registration to list a WebDAV endpoint as a capability. All we would 
need to do to make that happen is bless an IVOA std URI to represent the 
WebDAV standard.

So .. given a 'vos://', take everything before the first '!', and pass 
it to a 'RegistryResolver' service which responds with the VOResource 
document.

If you want to use WebDAV as the protocol, then look for a 'std:WebDAV' 
capability in the list of service capabilities.

If you don't want to implement the full VOSpace webservice API, you 
don't have to.

I don't see a problem with registering a VO service with a simple 
VOResource document that just lists a 'std:WebDAV' capability.

This would enable you to use a standard WebDAV server to provide the 
workspace your users want, and at the same time be able to register it 
as a VO service and point to objects within it using 'vos://' URLs.

----------------

On the other hand, if resolving the 'vos://' into the service endpoint 
is the issue, because a standard desktop app doesn't know what to do 
with a 'vos://' URI, then Walter and Paul are right, we should just use 
'http://' URLs.

I agree that for most client-server use cases the standard WebDAV 
probably already does everything we need. The only caveat is that the 
only way to find out if a 'http://' service actually supports WebDAV is 
to try using it. If it does not support WebDAV then it will respond with 
an error - which is fine, we just need to document that.


Hope this helps,
Dave

--------
Dave Morris
Software Developer
Wide Field Astronomy Unit
Institute for Astronomy
University of Edinburgh
--------