RE: totalItems vs void:triples

On 14 Okt 2014 at 12:38, Ruben Verborgh wrote:
>> +1, totalItems was always intended to be exact...
> 
> I'm not sure if this is a good idea.
> That might be very hard to deal with for some applications;

You should have also included the second paragraph:

   ... whatever that means in practice. The thing is that as soon as you
   receive that triple, the server's state may have already changed. I
   would thus prefer to avoid to define it too precisely/strictly.

I agree that it might be difficult for some applications and given that we
deal with a distributed system it sometimes is actually impossible.
Nevertheless, I think the expectation for clients should be that this is a
(reasonably) accurate number. If the server returns a collection (non-paged)
and includes totalItems it wouldn't make much sense if that number doesn't
correspond to the items in the collection.

> what does it matter if this number is rounded?

In the example above, the client would have to count the items instead of
just re-using the server-provided totalItems property. But of course there
are many applications where it doesn't matter.


> If we look at most human pages on the Web;
> total numbers are regularly an estimate.

Yeah, things like number of search results are but typically the number is
accurate.


> What matters is: is there a next page link?
> Are there items on this page?

Right. Nevertheless some applications (e.g. rendering UIs) can be simplified
if the totalItems property is "reasonably accurate". That's why I would like
to avoid defining it strictly and instead slightly tweak the explanation in
the TPF spec to avoid inferences as the one Kjetil made :-)

Makes sense?


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 14 October 2014 10:52:43 UTC