<div dir="ltr"><div>Hi Sonia,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 10, 2020 at 5:34 AM Zorba, Sonia &lt;<a href="mailto:sonia.zorba@inaf.it">sonia.zorba@inaf.it</a>&gt; wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">However the job requires to specify a protocol to use, but in this case it is an internal operation, so we thought to use a custom protocol with no endpoints, for example:<br><br><span style="font-family:monospace">&lt;vos:transfer xmlns:vos=&quot;<a href="http://www.ivoa.net/xml/VOSpace/v2.0" target="_blank">http://www.ivoa.net/xml/VOSpace/v2.0</a>&quot; version=&quot;2.1&quot;&gt;<br>  &lt;vos:target&gt;vos://<a href="http://example.com" target="_blank">example.com</a>!vospace/mydata1&lt;/vos:target&gt;<br>  &lt;vos:direction&gt;pullToVoSpace&lt;/vos:direction&gt;<br>  &lt;vos:protocol uri=&quot;urn:tape-recall&quot;&gt;&lt;/vos:protocol&gt;<br>&lt;/vos:transfer&gt;</span><br><br>In the beginning we thought to perform this operation as part of the asynchronous download (pullFromVoSpace), but in that case the job had to stay in the pending phase until the files were copied to the disk, with no possibility to check the status of the copy. Rethinking about it, it was clear that this copy operation is conceptually different from the download, so it has to be handled as a separate job, that is preparatory for the download. In that case using the pullToVoSpace operation seemed more appropriate.<br><br><div>Do you think that this is the correct approach to use? Did someone build something similar?</div></div></blockquote><div><br></div><div>Our implementations of VOSpace at CADC don&#39;t yet implement pullToVoSpace. So, I can&#39;t speak from experience, but I believe it is absolutely the correct vospace &#39;direction&#39; to use to implement your tape import requirement.  <br><br>Regarding the &#39;phase&#39; in the asynchronous pullFromVoSpace operation:  the specification is probably not clear enough about how the jobs phases reflect transfer negotiation and the resulting byte transfer.  With our &#39;vault&#39; implementation (the one based on distributed object storage) we took a different approach:  our jobs are in the EXECUTING phase during byte transfer, and then are set to COMPLETE or ERROR when that&#39;s done.  However, this is problematic as the service handling the byte transfer must make a callback to vospace to set the final phase.  This introduced an undesirable coupling between vospace and the service handling the byte transfer.  Also, since that callback can fail, we need to monitor and correct those failures in an out-of-band process.  If we get a chance to refactor this we will probably choose to set the phase to COMPLETE or ERROR immediately after transfer negotiation is complete, and consider the ensuing byte transfer an operation that is outside the scope of the VOSpace protocol.</div><div><br>Cheers,</div><div>Brian</div></div></div>