<div dir="ltr"><div>Hi Brian,<br></div><div class="gmail_quote"><br><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"><div class="gmail_quote"><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></div></div></div></blockquote><div><br></div><div>Thank you for confirming that we are interpreting correctly.<br></div><div> </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"><div class="gmail_quote"><div>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></div></blockquote><div><br></div><div>In the recommendation document, the first pullFromVoSpace example ends with &quot;On successful file transfer completion the job will be COMPLETED&quot;, so it seems that your implementation is following the recommendation. Do you think that this behaviour could be redefined in newer versions of the document?</div><div><br></div><div>I&#39;m worried about the coupling between vospace and transfer service too, but I think that it happens also in another situation: setting the  busy flag of the node to true during the byte transfer for the pushToVoSpace operation. Is that correct or am I missing something?</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks,</div><div class="gmail_quote">Sonia</div><div class="gmail_quote"><br></div></div>