Pagination in Queries

[dshanske]

This covers the concept of adding pagination to queries. This would be an alternative to the simpler offset #36 parameter.

Pagination was originally noted in #4 as part of multiple suggestions and is based on the Microsub spec https://indieweb.org/Microsub-spec#Paging for paging. A summary adapted from there is noted below.

For queries that paginate their results, there is an additional object returned with the values needed to page through those results.

"paging": {
"before": "xxxxx",
"after": "xxxxx"
}

The "before" and "after" values are arbitrary strings. This allows the server to internally use whatever specific implementation is most appropriate for its backend technology. (Often this will be either a timestamp or a unique ID identifying the first and last items in the returned list.)

• If there are any items returned in the response, the server MUST return a "before" value that will retrieve items before all the returned items in the list.
• If there are no items returned in the response, the server MUST NOT return a "before" value.
• If there are additional items available that were not returned in the response, the server MUST return an "after" value that will retrieve the next page of items.
• If there are no more items available, the server MUST NOT return an "after" value.

[jalcine]

I think this is missing one more case that Koype handles, if there's no more preceding items in the list, there should be no expectation of a before. Unless this is some way to always get the “newest” thing by sending the same before value over and over.

(Originally published at: https://jacky.wtf/2022/7/_TEm)

[dshanske]

@jalcine I think that's exactly what Microsub describes as how to poll for new content

[jalcine]

Noted!

(Originally published at: https://jacky.wtf/2022/7/QXZe)