VOSpace: Content-Length on transfer negotiation

[Brian Major]

Hi Dave,

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.

Brian

On Fri, Feb 6, 2015 at 7:16 AM, Dave Morris <dave.morris at metagrid.co.uk>
wrote:

> 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
>



-- 
Brian Major

Canadian Astronomy Data Centre
Centre canadien de données astronomiques

National Research Council Canada
Conseil national de recherches Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20150508/065de9e7/attachment.html>