Implementation thoughts on discussion points

Matthew Graham mjg at
Tue Oct 6 14:33:34 PDT 2009


Firstly, in addition to the discussing this on the list, I have copied  
these points on the VOSpace 2.0 discussion page ( 
) for posterity.

>> 1)   Pagination
>> 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:
>> {min|max| 
>> properties}
>> 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 asynchronous activity.
> +1. I feel more RESTed already :)
> "The ordering is determined by the server": yes, but we should be  
> careful of the details. The ordering must be consistent between  
> calls such that each {limit, offset} is drawn from the same, ordered  
> sequence. That's implied, of course, but I would state it explicitly.
> What happens if a client specifies {limit, offset} in a GET request  
> to a leaf node? Do we treat it as an error or ignore the paging  
> parameters?

The server should ignore the paging parameters and just return the  
appropriate level of information.

>> 2) Simple HTTP GET for client-server transfers
>> The aim here is to maintain the protocol negotiation capability to  
>> support
>> advanced protocols, but adding simple retrieval access via HTTP as  
>> well for
>> 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.
> I have two problems here.
> First, the mapping for a node from the vos:// URI to http:// is  
> broken. That's a bigger problem that I won't detail here, but it has  
> to be sorted out before this can work.

I thought that we had agreed in Strasbourg that there was no inherent  
mapping between the vos:// URI and the http:// one but that one would  
use a registry to resolve the correct VOSpace endpoint. However, the  
location relative to the root node of the space would remain  
unchanged. Thus:


would use  the registry to figure out the HTTP URL of the root node  
(e.g. and then the file would be :


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the vospace mailing list