Back in my J2EE days I knocked out a paginator server-side component that constructed a guaranteed ordering of items. This paginator stored its paging state in memcached with a consistent hash for a key in order to share paging indices among similar requests. Staleness was handled with a periodic check for additional result, or cache expiration after a while. The client had to handle the stale check and the "oops, sorry, let me refresh the paged list..." after idle. This was only suitable for roughly half the use cases.<p>It was complex, but it worked. Thank goodness I didn't have to deal with infinite scrolls back then.
Good article, I do wish it would talked about big-O and arbitrary sort orders.<p>Let's say there's lots of columns/fields to sort by. Not quite an arbitrary sort (e.g. can't sort by area when given a width and height column) but its still pretty flexible. Is is possible to get a O(1) pagination while avoiding the rolling-shutter problem and deleted-anchor problem?<p>Getting around the deleted-anchor problem with ordered-ID's seems like just using ID's as a index. Not a bad trick, but seems like it isn't generalizable for all different kinds of sorts.
I've been facing the issue of shifting data with the eBay browse api. Unfortunately they don't offer ID based pagination. What's the best way to deal with it, manually track queried data yourself?