<div dir="ltr"><div dir="ltr">Hi Dave,<br>thanks for all your replies and for creating a dedicated thread for each discussion point.<br><br>I agree that allowing multiple targets increases complexity, however I don't think this requirement is so specific to our use case, so I'll try to insist a bit more on it.<br><br>Probably there are cases where having multiple targets doesn't make much sense, so the service developers should add some checks and return proper exceptions for those cases.<br>For example, by default a pullFromVoSpace operation could accept only one target. However, a pullFromVoSpace operation with a view that returns a tar/zip archive would make sense.<br><br> <vos:target>vos://..../file-one</vos:target><br> <vos:target>vos://..../file-two</vos:target><br> <vos:direction>pullFromVoSpace</vos:direction><br> <vos:protocol uri="ivo://<a href="http://ivoa.net/vospace/core#httpget">ivoa.net/vospace/core#httpget</a>"/><br> <vos:view uri="ivo://my-registry/vospace/views#tar" /><br><br>Other file storage services (e.g. Google Drive or Owncloud) allow selecting multiple files in the same folder and downloading them as a zip. I think users are very used to this feature and expect to be able to do something like this if they use the service from a UI.<br><br>We had already implemented the multiple targets support as you are suggesting (by creating a new container node containing a reference to all the selected nodes and then performing the pullFromVoSpace operation on it), however we are not satisfied by this solution, because it brings additional complexity too:<br><br>- the node exists just to support the transfer operation and has to be deleted at the end of it;<br>- during the operations the user would see some unexpected nodes on his/her folders, so we had to add an extra property to hide them from the UI; these nodes have no meaning for the user, they just exist as a workaround to allow multiple targets operations; it seems like an internal implementation detail that we have to hide;<br>- there are many different HTTP calls just for starting a single operation and this visibly slow down the UI, making the user experience worse.</div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The standard allows the service to offer multiple protocol endpoints for <br>
a single transfer. If we added support for multiple targets, then we <br>
would need to define how to link the different targets to the different <br>
endpoints.<br></blockquote><div><br></div><div>If a pullFromVoSpace operation accepts multiple targets only when its result is a single entity (like in the tar archive case) there is no problem. Otherwise, I agree with you that handling the link between each target and its endpoints sounds quite complex. We hadn't considered this particular case, so thanks for starting a discussion about it.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If we added support for multiple targets, would this include targets <br>
from different locations? If not, then we would need to define how we <br>
would prevent them.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<vos:targets><br>
<!--+<br>
| This is a target in the CADC VOSpace.<br>
+--><br>
<vos:target>vos://CADC/..../file-one</vos:target><br>
<!--+<br>
| This is a target in the INAF VOSpace.<br>
+--><br>
<vos:target>vos://INAF/..../file-two</vos:target><br></blockquote><div><br>What if the target is single but it is a container node containing nodes from different locations? I think that this is already allowed by the standard and implementations should already be able to handle these cases. I don't think this problem is specific to the multiple targets case.<br><br>It seems that CADC VOSpace UI already provides the possibility to select multiple files and download a zip archive. I'm curious to know how they handled that use case.<br><br>In any case I think that allowing multiple targets could be an optional feature, so only facilities that really need it have to do the extra work that this feature requires.</div><div><br></div><div>Cheers,</div><div>Sonia</div><div><br></div></div></div>