The code that generates list-structured pages spits out a page of n items, then saves a closure that will keep going if asked. Since closures can't conveniently be written to disk, you have to gc them after a while or you'll have a memory leak.
It may be overkill to use this approach if you just want to generate the frontpage, but the advantage is that it's very general. You're not limited to displaying a range of items stored in a list somewhere; you could be displaying things you're computing on the fly.
> People complain often about traditional offset/limit pagination
I haven't heard any. What kinds of complaints have you heard?
I appreciate the generality and elegance of the closure approach, but the links expire far too quickly for my taste. About once a week I read a page slowly enough that the "next" link is dead by the time I click it.
When you removed or upped the limit on how far back one can look (this was done a year or a bit more ago?), that change was made to news/ and newest/, but not to classic/ (still cuts off at 210 items). Any chance of also lifting/upping the limit on classic/ ? Once in a while, I like to dig back a bit through it.
I didn't increase the upper limit for news and newest. I changed the code so there was no limit. I can't do that with classic because I have to do a sort before I display anything. The front and new pages are simply displaying already sorted lists, so they can be written as if the lists were endless. But with classic I have to pick some number of items in advance to sort and then display.