UWS as a REST protocol - VOSpace & WebDAV

Paul Harrison pharriso at eso.org
Mon Mar 5 01:14:59 PST 2007


On 04.03.2007, at 20:01, Matthew Graham wrote:

> Hi,
>
> The first VOSpace implementation I produced two years ago had a  
> full WebDAV interface on it but that was more to act as one of the  
> data transfer methods than to handle metadata requests.

I am talking about doing the *metadata* management through WebDAV -  
not just data transfer.

> Conceptually VOSpace has a messaging channel for the metadata  
> (currently SOAP) and a transfer channel for the actual data bytes  
> (whatever protocol the space wants to use): WebDAV actually seems  
> like overkill for the messaging channel since all you need is CRUD- 
> support and not all the other extensions that WebDAV provides -  
> it's the old using-a-jack-hammer-to-put-in-a-carpet-tack analogy.

Looking at the standards (http://www.webdav.org/specs/), the core  
WebDAV standard RFC 2518 already provides several features that we  
want that are *not* in VOSpace 1.0 - e.g. collections, locking, as  
well as having more complete definition of properties  - we may or  
may not want versioning (RFC 3253),  we definitely need searching  
(DASL),  we have said that we want links (WebDAV bindings) - and we  
need authorisation mechanisms (RFC 3744) - so there is a huge overlap  
in scope with what we want out of VOSpace. My judgement on this is  
that the main things that VOSpace has that WebDAV does not are

0. A location independent vos: URI scheme.
1. Asynchronous data tranfer with transport protocols other than http
2. views - though as has been pointed out already most of this  
functionality can be replicated with the Accept http header.

The only thing that WebDAV has that we probably do not want is the  
versioning.

If we are talking about throwing out SOAP web services in the IVOA  
then the original motivation for designing VOSpace in the way that it  
has been is called into question - perhaps VOSpace can be reduced  
almost to a vos: URI resolving service, and all interactions with a  
particular VOSpace are done via WebDAV.

> In fact, I think that this is not the interface to use if we are  
> talking about proposing our *own* extensions to WebDAV - we then  
> end up with a homegrown interface that every desktop computer on  
> the planet cannot use just as is.
>
well if they remain our own *private* extensions to webdav then of  
course current WebDAV clients would not implement them, but if we  
were to engage in the WebDAV standardization process then there might  
be some chance of widespread adoption. Even if we did have only  
private extensions to WebDAV, it would aid the writing of clients if  
we could take existing webdav client code and simply add the  
extensions rather than having to re-write all the functionality that  
that they provide to support our own RESTful VOSpace interface.

>    Cheers,
>
>    Matthew
>
>
>
> Paul Harrison wrote:
>>
>> On 26.02.2007, at 17:46, Matthew Graham wrote:
>>
>>> I think that this looks very promising and is line with similar  
>>> thoughts that I have had about a RESTful interface for VOSpace -  
>>> I've started writing these up and will hopefully have time to  
>>> finish this some time soon.
>>
>> surely the overwealmingly predominant RESTful file management web  
>> service is WebDAV? Just about every desktop computer on the planet  
>> has a WebDAV client bundled with the OS.  I'm writing an  
>> implementation of VOSpace that also has a Webdav interface to the  
>> same metadata to investigate the possibilities. Perhaps we should  
>> be proposing extensions to WebDAV to cope with some of the useful  
>> VOSpace qualities - e.g. physical location independence via the  
>> vos: scheme, and asynchronous data transfer.
>



More information about the grid mailing list