On Mon, 14 Aug 2006, Markus Dolensky wrote:
> 5.2.3
> The paging mechanism is certainly a 'nice to have'. Judging from the list of
> exceptions it is one of the most complicated concepts in this spec. Therefore,
> I'd suggest to provide means to filter node listings instead. Filtering by node
> property value and owner (user/creator), for instance.
>
> Paging is not enough on its own without some prior sorting that brings the
> relevant records to the top. Otherwise it is likely that one has to page all the
> way to the end anyway.
>
> So again, it appears rather complicated but inefficient from a user's
> perspective and one can live without it in level 1.
Markus,
I think you may have misapprehended the point of this feature. Paging is not mainly intended as a convenience for users so that they get relevant records without looking at all the data, but as a protection for software, both at the server and at the client ends. Without such a mechanism a client might in principle be delivered a multi-megabyte list of nodes which could put strains on its resource usage. Similarly, a server might have to stage such a response prior to sending it. In fact in many or most situations in which this facility is used, the expectation will be that the client does retrieve all the nodes in the list rather than just one or a few pages, but this can be effected with both ends of the connection able to budget their storage in a controlled way during the transfer.
Disclaimer: I've not really been involved in VOSpace design, so if it's me whose misunderstood here then (a) apologies and (b) can someone who does understand it post a correction.
Mark
-- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2006-08-15Z11:09:24