<div dir="ltr">Hi everyone,<div><br></div><div>Here at the CADC we have had similar talks about VOSpace, but not necessarily about how it compares to WebDAV. A question we are trying to answer is "What does VOSpace offer for astronomers?" Indeed, there is very little in the specification that is specific to astronomy. It is a well-designed, general-purpose virtual storage system specification. However, there are some things to consider:</div>
<div><br></div><div>- There is real value in VOSpace Views. This feature allows the CADC to deliver to the user only the bytes in which they are interested, not just whole files.</div><div><br></div><div>- The specification has been flexible enough to allow the CADC implementation to have customizations and optimizations in our supporting storage systems that may be running on heterogeneous infrastructures. If a lower-level standard is adopted will there be such flexibility? </div>
<div><br></div><div>That said, I agree with Dave here--I think it's time to step back and look at the big picture and the role and look of VOSpace in the future.</div><div><br></div><div>Here are some technologies/articles you may find interesting that pertain to this discussion:</div>
<div><br></div><div>- A federated storage system build on WebDAV: Dynamic Federations (<a href="http://www.dynamicfederation.org/DynFed/Welcome.html" target="_blank">http://www.dynamicfederation.org/DynFed/Welcome.html</a>)</div>
<div>- An similar article on that here: <a href="https://indico.cern.ch/event/218328/" target="_blank">https://indico.cern.ch/event/218328/</a> I think you can substitute "HEP" with "Astronomy".<br>
- The object storage system ceph: (<a href="http://ceph.com/" target="_blank">http://ceph.com/</a>)</div><div>- A possible alternative to VOSpace Views: The JPEG 2000 Interactive Protocol (<a href="http://www.jpeg.org/jpeg2000/j2kpart9.html">http://www.jpeg.org/jpeg2000/j2kpart9.html</a>) and analysis from Andreas here: <a href="http://arxiv.org/abs/1307.5123">http://arxiv.org/abs/1307.5123</a></div>
<div><br></div><div>Brian</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 15, 2014 at 10:48 AM, Dave Morris <span dir="ltr"><<a href="mailto:dave.morris@metagrid.co.uk" target="_blank">dave.morris@metagrid.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Walter,<br>
<br>
I am one of the authors of the original VOSpace specification, along<br>
with Paul Harrison, Matthew Graham and Guy Rixon.<br>
<br>
Your comparison of the main features of WebDAV and VOSpace are correct.<br>
<br>
If what your users want is to be able to drag and drop files from their<br>
desktop to a remote folder using a standard file browser, then WebDAv is<br>
indeed probably the best protocol to use. In fact, implementing the full<br>
VOSpace specification will probably just get in the way. WebDav covers<br>
everything you need and the many existing 3rd party implementations mean<br>
it is a lot simpler to deploy.<br>
<br>
You are right that asynchronous 3rd party transfers are responsible for<br>
much of the complexity in the VOSpace specification.<br>
<br>
At the time, interoperable asynchronous 3rd party transfers was one of<br>
the reasons for developing the VOSpace specification. One of the aims of<br>
our project was to be able to process as much as possible 'in the cloud'<br>
and only transfer the final processed results to the the client desktop.<br>
As a result, a lot of the work on the VOSpace specification was designed<br>
to handle server to server transfers, rather than server to client.<br>
<br>
<br>
Your analysis of vos: URI scheme is correct, part of its function is<br>
indeed to act as a name resolver service, similar to DNS.<br>
<br>
Very similar in fact to the 'Name Mapping Authority Host' in the ARK<br>
scheme that Norman described. Although the steps involved in resolving<br>
the service URL via the registry are a bit more complex than they should<br>
be be due to limitations in the ivo: registry URI scheme.<br>
<br>
<br>
Regarding the suggestion of replacing VOSpace with WebDAV plus<br>
extensions.<br>
<br>
I agree - it probably is time for a fresh look at the problem, a lot has<br>
happened in the last 10 years (back in 2004 we still thought SOAP was a<br>
good idea). However, if it really is a re-write from scratch, then to<br>
avoid confusion and interoperability issues we should probably call it<br>
by a different name and use a different URI prefix.<br>
<br>
Regards,<br>
Dave<br>
<br>
--------<br>
Dave Morris<br>
Software Developer<br>
Wide Field Astronomy Unit<br>
Institute for Astronomy<br>
University of Edinburgh<br>
--------<br>
<div><div><br>
<br>
<br>
<br>
On 2014-05-15 06:19, Walter Landry wrote:<br>
> Hello Everyone,<br>
><br>
> At our datacenter, we want to implement some kind of workspace for our<br>
> users. So the natural thing to do is to look at VOSpace and see if it<br>
> could be bent to our needs. However, I am also familiar with WebDAV<br>
> [1],<br>
> and I am having a hard time understanding what advantages VOSpace<br>
> brings. Just to run down the basics about WebDAV:<br>
><br>
> 1) WebDAV supports much of the functionality in VOSpace, including<br>
> all of these items lifted directly from the VOSpace introduction<br>
><br>
> * add or delete data objects<br>
> * manipulate metadata for the data objects<br>
> * obtain URIs through which the content of the data objects can be<br>
> accessed<br>
><br>
> 2) WebDAV is a mature, established standard deployed worldwide on a<br>
> variety of machines. Every major desktop OS has WebDAV built in,<br>
> and you can get clients and servers for every operating system on<br>
> almost any hardware, including phones, tablets, and supercomputers.<br>
><br>
> 3) WebDAV has a number of implementations of the client and server in<br>
> every programming language you can think of.<br>
><br>
> 4) WebDAV is based on http, so it is easy to layer any of a number of<br>
> authentication schemes on top.<br>
><br>
> 5) WebDAV has an easily understood filesystem-like API.<br>
><br>
> In contrast, the only compelling feature of VOSpace I can think of is<br>
> the ability to initiate 3rd party transfers. But it would seem better<br>
> to add a trivial extension to WebDAV rather than creating a completely<br>
> new protocol.<br>
><br>
> Moreover, the API for VOSpace is much more complicated, with a lot of<br>
> indirection. The vos: URI scheme in particular feels like a<br>
> reinvention of DNS for a benefit that I do not see. It almost goes<br>
> without saying that I have not seen much interest in VOSpace outside<br>
> of astronomy.<br>
><br>
> Given all this, it feels like the best use of my time would be to<br>
> install mod_dav on my Apache server and be done in short order. I<br>
> would guess that my users would even be happier than if I used<br>
> VOSpace. It is pretty addictive to be able to drag and drop from your<br>
> desktop to a remote WebDAV folder using the standard file browser.<br>
><br>
> Now, I am aware that this has been discussed before. I have also<br>
> spoken personally with one of the authors of VOSpace. Yet I still do<br>
> not quite see the need for VOSpace. Could someone enlighten me?<br>
><br>
> Thanks,<br>
> Walter Landry<br>
> <a href="mailto:wlandry@caltech.edu" target="_blank">wlandry@caltech.edu</a><br>
><br>
> [1] <a href="http://webdav.org/" target="_blank">http://webdav.org/</a><br>
> [2] <a href="http://www.ivoa.net/forum/grid/2007-March/001713.html" target="_blank">http://www.ivoa.net/forum/grid/2007-March/001713.html</a><br>
> <a href="http://www.us-vo.org/pipermail/techwg/2005-February/000793.html" target="_blank">http://www.us-vo.org/pipermail/techwg/2005-February/000793.html</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font color="#999999">Brian Major<br><br>Canadian Astronomy Data Centre<br>Centre canadien de données astronomiques<br><br>National Research Council Canada<br>
Conseil national de recherches Canada</font></div>
</div></div>