VoSpace 2.x

PullDataFromVoSpace

Request a URL that the client can read data from.

This method used to be called ExportInit

This will probably be the primary data access method for reading data from a VoSpace . The client requests access to a data node, and the server responds with a URL that the client can read the data from.

Parameters

• Target - The URI of an existing data node. note
  • vos://[service]/000-517
  • vos:///000-517
  • vos://[service]/path/my%20results
  • vos:///path/my%20results
  • vos:///my%20results

• Format - The URI of the data format.
  • ivo://org.astrogrid.vospace/formats/binary
  • ivo://org.astrogrid.vospace/formats/votable-1.0

• Protocol - The URI of the transfer protocol.
  • ivo://org.astrogrid.vospace/protocols/http-get
  • ivo://org.astrogrid.vospace/protocols/dime-get

Returns

A <node> element for the node, containing

• The full URI encoded identifier for the node. note
  • vos://[service]/000-517
  • vos://[service]/my%20results
  • vos://[service]/path/path/my%20results

• The node name as a plain string
  • 000-517
  • my results

• Type - The URI of the node type
  • ivo://org.astrogrid.vospace/types/data.node

• Properties - The set of name value properties for the new node

Plus, a <transfer> element, containing details of the data transfer.

• The URI of the transfer object (if the server supports status queries)
  • vos://[service]/[ident]

• Format - The URI of the data format.
  • ivo://org.astrogrid.vospace/formats/binary
  • ivo://org.astrogrid.vospace/formats/votable-1.0

• Protocol - The URI of the transfer protocol.
  • ivo://org.astrogrid.vospace/protocols/http-get

• A <location> element containing details of where to get the data from

A standard http transfer only requires the URL to send the data to

    <location xsi:type="HttpPutLocation">
        <url>http://[host]/[path]</url>
    </location>

A SOAP DIME transfer requires the endpoint of the service, and an identifier for the transfer.

    <location xsi:type="HttpPutLocation">
        <url>http://[host]/[path]</url>
        <ident>5117-00BC6</ident>
    </location>

Other protocols may require different a set of params.

• Status - For a transfer that has not ben used yet, the status should be 'ready'

Throws

• The service will throw a NodeNotFound exception if the target node does not exist.

• The service may throw a OperationNotSupported exception if it does not support the requested transfer protocol.
• The service may throw a OperationNotSupported exception if it does not support the requested data format.

• The service may throw an InternalFault exception if an operation fails.
• The service may throw a PermissionDenied exception if the user does not have permissions to perform the operation.

• The service will throw a LinkFound exception if the target path includes a link. note
• The service will throw a LinkFound exception if the target node is a link. note

Notes

• The <target> identifier in the request can be full a URI including the service identifier and node path.
  • vos://[service]/000-517
  • vos://[service]/path/my%20results

• The <target> identifier in the request can be a relative URI just containing the node path.
  • vos:///000-517
  • vos:///path/my%20results

• The <node> identifier in the response must be full a URI including the service identifier and node path.
  • vos://[service]/000-517
  • vos://[service]/path/my%20results

• The URL or URI supplied in the response should be considered as a 'one shot' URL.
  • A VoSpace service connected to a standard web server may return the public URL for the data.
  • However, a different implementation may create a unique URL specifically for this transfer, which can only be used once, and may have a limited lifetime.

• The transfer information may have a limited lifetime, and may be deleted by the server when it has reached its expiry date.
• The transfer location may have a limited lifetime, and may be deleted by the server when it has reached its expiry date.

• Link nodes are not part of the V1.0 specification, they will be defined in a future version of the specification.
• LinkFound exceptions are defined in this version of the specification to enable future versions to extend the current interface, rather than require a completely new interface type.

Questions

• Should we make the default format binary and allow the <format> element to be optional ?

• If we use xsi:type on the <location>, then do we need the <protocol>.
• Or should the xsi:type be on the <transfer> or <protocol> element ?

• Should the server response include details of the lifetime of the transfer object ?

• What status codes do we want for transfers, or can we use URIs ?

• What URI syntax should we use for refernces to transfer objects ?
• Should the transfer object reference be moved to a future version ?

-- DaveMorris - 18 May 2006