<div dir="ltr">Hi Dave,<div><br></div><div>Thanks for your feedback. I think I prefer your option #2 below. Content-length (or byteCount, to fit better with the existing keepBytes) seems independent of the protocol(s) of the transfer. </div><div><br></div><div>Brian<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 6, 2015 at 7:16 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree with the concept.<br>
<br>
I'd like to suggest a couple of alternative implementations.<br>
<br>
1) Could this be passed as a property of the protocol? If so, then this<br>
could be done now without any changes to the XML schema. Disadvantage is<br>
that it would have to be repeated if multiple protocols were<br>
offered/selected.<br>
<br>
2) If we are going to change the XML schema, rather than adding a<br>
specific element for this case, we add a generic <properties> element to<br>
<transfer> which would enable us to add more things like this in the<br>
future without having to change the XML schema every time.<br>
<br>
Using the property model would allow us to define a byte-count property<br>
for files now, and a row-count property for database tables later.<br>
<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>
On 2015-02-04 21:34, Brian Major wrote:<br>
> Hello grid listeners,<br>
><br>
> I'd like to propose the addition of an optional content-length field to<br>
> the<br>
> transfer document used to request endpoints for moving data to and from<br>
> VOSpace. However, this would only be applicable when the requested<br>
> transfer direction is either pushToVoSpace and pullToVoSpace.<br>
><br>
> VOSpace implementations must produce a set of transfer endpoints. In a<br>
> distributed storage system, the decision of creating endpoints for data<br>
> storage would be more informed if the system knew the size of the file<br>
> the<br>
> client was intending to upload. For example, a large file may only fit<br>
> in<br>
> a certain physical location.<br>
><br>
> This new field would not be meant to be used in the actual transfer<br>
> process<br>
> to confirm that the entire file has been received--that would remain<br>
> the<br>
> responsibility of the transfer protocol (HTTP, FTP, etc...).<br>
><br>
> Regards,<br>
> Brian<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><font size="2" 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></div></div>