On Oct 24, 2005, at 11:16 AM, James Holderness wrote:
A more sensible approach would be a single feed document containing
the top N results (where N is manageable in size). You could
subscribe to that as a non-incremental feed and you would know at
any point in time which were the top 10 results. There is no real
need for paging other than as a form of snapshot history (i.e. what
were the top 10 results last week).
That is certainly a good approach--allowing the number of results to
be determined dynamically by something in the URL, for example.
However, it could be useful to limit the chunk size and allow paging
for people who want more. For example, you might allow a maximum of
50 results per chunk, and then support ETags. That way, if somebody
wants to monitor the top 250, they can send 5 requests, and if most
of the time there are no changes, they'll get a lot of 304s, but if
occasionally something changes in the last chunk of 50 for example,
they're only downloading 50 results each time something changes.
There are of course other approaches, like support for just sending
the diffs. But that would probably more difficult for most people to
implement, and may be less likely to be supported by a wide variety
of clients.
Another reason for wanting to limit the number of results per query
(and support paging for those who want more) is to avoid bandwidth
waste if someone accidentally ads an extra digit to the desired
number of results; or tries to waste your system resources by
requesting huge result sets (but dropping the connection before using
up their own bandwidth actually receiving the whole result set); or
has a client that doesn't support paging or diffs or ETags or
anything, and wants a huge result set (and you don't want to
accommodate them since it would use so much bandwidth), etc.
Once again, I have to ask the same question I asked Thomas: do you
have a problem with Mark's next/prev proposal as it stands, or are
you just arguing with me because you think I'm wrong? If the
latter, feel free to just ignore me. We can agree to disagree.
Unless we're discussing a particular proposal I don't see the point.
I have a problem with not having link relations specific to paging
through a feed's current state. I'm fine with having general chain
navigation link relations, but hope that we'll get something specific
to paging and that people will use it instead of the general link
relations. I've spoken my peace on that and have given up swimming
against the tide, but am still willing to discuss specific related
issues.
