UWS as a REST protocol - VOSpace & WebDAV

[Matthew Graham]

Hi,

It seems as though you've come to exactly the same conclusions I made 
about WebDAV and the significant overlap it has with VOSpace, although 
for VOSpace 1.0 most of this is moot. I actually thought that the 
biggest difficulty was supporting the different data transfer methods. 
In terms of implementing VOSpace with WebDAV, it was fairly 
straightforward - I used the Apache WebDAV kit as a base - and I had it 
working with both a filestore backend and a database backend.

    Cheers,

    Matthew

Paul Harrison wrote:
>
> 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.
>>
>