- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Tue, 14 Oct 2014 09:51:39 -0700
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-hydra@w3.org
On Oct 14, 2014, at 3:52 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote: > 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. Yes, but it's the paged collection issue that is more challenging. As totalItems is a property of a PagedCollection, then every page in the collection also has this. If we imaging a PagedCollection representing a frequently changing log, then requiring every page of the collection to have exactly the same/accurate number becomes cache-busting. Maybe this suggests that the notion of there being only a single component of a PagedCollection which references (or contains, in one case) individual Pages simplifies this. That way, cached representations of each Page wouldn't need to be invalidated as information is added, only the PagedCollection with totalItems/first/next/last, the last page, and potentially the next to last page would need to change. I think Ruben proposed something like this. Gregg >> 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 16:52:10 UTC