VOSpace: Content-Length on transfer negotiation

[Dave Morris]

I agree with the concept.

I'd like to suggest a couple of alternative implementations.

1) Could this be passed as a property of the protocol? If so, then this 
could be done now without any changes to the XML schema. Disadvantage is 
that it would have to be repeated if multiple protocols were 
offered/selected.

2) If we are going to change the XML schema, rather than adding a 
specific element for this case, we add a generic <properties> element to 
<transfer> which would enable us to add more things like this in the 
future without having to change the XML schema every time.

Using the property model would allow us to define a byte-count property 
for files now, and a row-count property for database tables later.

Dave

--------
Dave Morris
Software Developer
Wide Field Astronomy Unit
Institute for Astronomy
University of Edinburgh
--------

On 2015-02-04 21:34, Brian Major wrote:
> Hello grid listeners,
> 
> I'd like to propose the addition of an optional content-length field to 
> the
> transfer document used to request endpoints for moving data to and from
> VOSpace.  However, this would only be applicable when the requested
> transfer direction is either pushToVoSpace and pullToVoSpace.
> 
> VOSpace implementations must produce a set of transfer endpoints.  In a
> distributed storage system, the decision of creating endpoints for data
> storage would be more informed if the system knew the size of the file 
> the
> client was intending to upload.  For example, a large file may only fit 
> in
> a certain physical location.
> 
> This new field would not be meant to be used in the actual transfer 
> process
> to confirm that the entire file has been received--that would remain 
> the
> responsibility of the transfer protocol (HTTP, FTP, etc...).
> 
> Regards,
> Brian