Implementation thoughts on discussion points
mjg at cacr.caltech.edu
Mon Oct 5 12:16:16 PDT 2009
Given that Dave and Doug are elsewhere this week, I a;m going to play
devil's advocate and make implementation suggestions for each of the
discussion points for you to shoot down:
The listNodes method is to be removed - listing will be possible with
a straightforward HTTP GET to the node. The representation returned
can be altered with the use of a 'detail' keyword:
When the node is a container, it will return a list of direct children
nodes in the container. Now if the container contains a lot of nodes
(>10000) then the client can specify a numerically limited subset
using 'limit' and 'offset' keywords:
The ordering is determined by the server.
The aim here is that listing no longer makes use of continuation
tokens but that pagination of results is controlled by the client.
findNodes can employ a similar mechanism but is directed against the
appropriate search resource and not the node since a search can be an
2) Simple HTTP GET for client-server transfers
The aim here is to maintain the protocol negotiation capability to
advanced protocols, but adding simple retrieval access via HTTP as
cases where nonauthenticated access is permissible.
The HTTP URL should be persistent, i.e., it should be possible for
multiple clients to retrieve the file given a single URL. Even where
authentication is required we might want to retain the same URL, but
merely require HTTPS to access it.
A view needs to specified to return the appropriate resource - a basic
HTTP GET call to a node just returns the resource representation
(listing). So the minimum call is:
This may result in a redirection to another endpoint if appropriate.
3) Parameterized version as alternate to XML representation
Instead of HTTP POSTing a transfer representation to the space (http://nvo.caltech.edu/vospace2.0/transfers
<protocol uri="ivo://ivoa.net/vospace/core#http put"/>
we can HTTP POST a parameterized representation:
This would return the URI of the transfer resource giving operational
details of the transfer such as the endpoint.
4) UWS for transfers
Under UWS, the elements in the transfer resource representation become
parameters in the UWS Job resource representation. A transfer job
could thus be created by a parameterized HTTP POST to the transfers
This would return the jobid and it could then be initiated with a POST
of a single parameter PHASE=RUN to the endpoint:
A transfer could be aborted at any time with a POST of a single
parameter PHASE=ABORT to the same endpoint.
5) Extra information requested
As part of the information returned in the resource representation of
a container, the amount of space available within that container
should be returned.
More information about the vospace