Proposals for VOSpace (paginated response)

[Dave Morris]

Hi Sonia,

You raised several good suggestions in your email. To avoid confusion 
I'll reply to each one in a separate email thread.

On 2021-06-11 13:31, Zorba, Sonia wrote:
> 7. On the getNode endpoint add parameters to perform paginated 
> requests.
> Useful for nodes having too many children.

Paginated response sounds simple, but it turns out to be complicated to 
implement.

We would need to define a design that does not put a heavy load on the 
server, can reliably handle the insertion or deletion of nodes between 
requests without producing duplicate rows in the results, and does not 
require the use of a relational database to implement it.

As far as I know, everyone who has looked at this has decided that it is 
easier to do it on the client side than on the server side. Perhaps 
someone would like to look at this again and propose a definition for 
how a paginated response could work?

For me, I see pagination as a client side display function rather than a 
server side data access function. Is there a strong use case for doing 
this on the server side ?

Bear in mind that even if we did define a new property for pagination, 
existing version 2.1 services would not understand it. So unless we make 
the new property mandatory, everyone adopts the new standard, and we 
deprecate the version 2.1 standard, clients would still have to cope 
with large responses from version 2.1 services.

Cheers
-- Dave

--------
Dave Morris
Research Software Engineer
Wide Field Astronomy Unit
Institute for Astronomy
University of Edinburgh
--------