2011-03-04, 19:48
Montellese Wrote:The way it currently is (and the way I think it is good) is that "total" shows the total number of items which could be retrieved when not limitting the number of items. If we don't return the total amount of available items a client never knows how many items actually exist (if the client prefers to use pagination). This is especially useful for remote control devices like the android remote where you don't want to retrieve all 2000 albums in one request but still need to know how many items are available.
I disagree. Total should still show the number of theoretically available items.
If you want to know the amount of returned items you can always calculate it from the values returned for "start" and "end".
doh, yeah thats true I just looked at the code and it does indeed return total as possible total which I agree is more useful than what I spoke of. Then you can query the possible numbers via start=0, end=0 which might be a useful indicator (which is why it was designed like that). My memory gets fuzzy it seems
So to formalize, given 10 items:
start=0, end=0 -> start=0, end=0, total=10. Returning 0 items
start=0, end=5 -> start=0, end=5, total=10. Returning 5 items
start=5, end=15 -> start=5, end=10, total 10. Returning 5 items
start=15, end=20 -> start=10, end=10, total 10. Returning 0 items
This is the behavior we want? When I rethink on it I agree this is the proper API. i.e. input start and end are indicators what you want returned start and end shows what you got while total shows what is available in total.