[kelnos]

The problem is, "what is page 2"? Ok, so it's "items 31 through 60." But that changes, very frequently. So when you hit the main page (results 1-30), HN has to remember what 31-60 is at that particular point in time, so when you later hit the More link, it can give you 31-60 for a time in the past.

Obviously it can't remember an infinite number of these, there's a limit, and how quickly you hit that limit probably depends on a combination of how many people are hitting the home page, and how often the order of items in the list is changing.

When HN was younger, you wouldn't see the expired link message that often, as fewer people were hitting the site, and the item order changed less frequently.

At least that's my theory.

[underwater]

Well currently the pagination implemented using a closure so there is obviously some state that is kept on the server and used to calculate what should appear when "next page" is clicked.

Why can't the link to page 2 include the data that would be available to the closure? That way the client is responsible for keeping track of the user's session, and not the server.

Edit: Here is the source: https://github.com/nex3/arc/blob/master/news.arc#L948 Looking at that has made me realise I can't read Lisp.

[bmm6o]

> The problem is, "what is page 2"?

Sure, most solutions to this problem will involve compromises and won't be perfect, but just about anything would be an improvement over the current situation.

[kelnos]

Yeah, good point. Considering that I have to go back to the front page and I lose the "older" page 2 results anyway, it'd be far preferable to just send me to a newer page 2. Could likely pretty easily implement that with a fallback query param, so the link could be something like "?fnid=foo&startitem=31" or whatever. If the fnid is no longer valid, fall back to the startitem param.