On 16.08.2006, at 10:39, Dave Morris 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.
>>
> Mark Taylor has already mentioned some of this.
> The paging mechanism is not really intended to display a series of
> separate pages to the user e.g. Google search results.
>
> As Mark has suggested, the reason for splitting the results into a
> series of pages is to enable the system to handle large numbers of
> files without overloading the server or client.
>
> There is no limit on the number of files in a space, and one of the
> target requirements was that the system should be able to handle
> lists of over 10^6 files without failing.
> Although this wouldn't be an ideal way of organizing the data, it
> is possible to imagine a complex workflow creating a huge number of
> intermediate temp files, or a VO event receiver that stored a
> record of all the events for it received. The paging mechanism
> enables us to avoid overloading the system if a client requested a
> list of the contents of a large space.
>
> It also enables GUI developers to make the system appear much more
> responsive.
> If a space contains a large number of files, a GUI client could
> start to render the first set of results as soon as it receives
> them, rather than wait for the whole list to arrive.
>
> Your suggestion of sorting or filtering the list based on node
> properties would indeed be a very useful facility.
> We are planning to add more functionality to the list mechanism,
> including the ability to search, filter and sort the results based
> on node properties.
> However, this will probably be added as separate search API in
> future versions of VOSpace.
I thought that we had agreed that basically in a 1.x version of VOSpace we would enhance the list function to have simple wildcarding facilities comparable to those for 'ls' in a unix shell, where a full search (analogous to unix 'find') would be part of a future API.
Paul. Received on 2006-08-16Z13:23:31