Implementation thoughts on discussion points

[Matthew Graham]

Hi,

Firstly, in addition to the discussing this on the list, I have copied  
these points on the VOSpace 2.0 discussion page (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/VOSpace20Spec 
) 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:
>>
>> http://nvo.caltech.edu/vospace-2.0/mjg/mytable1?detail= {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:
>>
>> http://nvo.caltech.edu/vospace-2.0/mjg/mydir1?limit=500&offset=2500
>>
>> 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:
>>
>> http://nvo.caltech.edu/vospace-2.0/mydata/table3?view=ivo://net.ivoa/core/views/votable-1.1
>>
>> 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:

vos://xyz.com!vospace/mydir/myimg/mydata.fits

would use  the registry to figure out the HTTP URL of the root node  
(e.g. http://efg.com/vospace) and then the file would be :

http://efg.com/vospace/mydir/myimg/mydata.fits.

	Cheers,

	Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/vospace/attachments/20091006/aa3a9719/attachment-0001.html>