I'm not sure if this question has been asked but it doesn't make a whole lot of sense to me. At least a dozen times I've hit the 'more' button to find the URL expired. Wouldn't it make more sense to have a page 2, page 3 etc?
Why does HN generate unique URL's for the 'more' pages?
1–10 of 44 posts
Re: Why does HN generate unique URL's for the 'more' pages?
#2Re: Why does HN generate unique URL's for the 'more' pages?
#3See this patent: http://www.freepatentsonline.com/6205469.html Also: http://www.hnsearch.com/search#request/all&q=expired+lin...
or, for a slightly less advertising-ridden interface, http://www.google.com/patents/US6205469
Re: Why does HN generate unique URL's for the 'more' pages?
#4See this patent: http://www.freepatentsonline.com/6205469.html Also: http://www.hnsearch.com/search#request/all&q=expired+lin...
Insane. How can that be called an invention? That's like patenting 'Stepping over obstacles in order to avoid tripping'.
Re: Why does HN generate unique URL's for the 'more' pages?
#5I'm not sure how the patent relates to the question. The UI issue is that a user traverses to the 2nd or 3rd page of viewing, go reads some articles or whatnot, and then comes back to find that he or she cannot move onto the 4th page.
It's frustrating.
Re: Why does HN generate unique URL's for the 'more' pages?
#6I'm not sure how the patent relates to the question. The UI issue is that a user traverses to the 2nd or 3rd page of viewing, go reads some articles or whatnot, and then comes back to find that he or she cannot move onto the 4th page. It's frustrating.
Arc server stores closures on server (see the patent for the similar technique). Links include unique ids of these closures. Closures expire. This has been explained numerous times here on HN, see the search link in my different comment.
Re: Why does HN generate unique URL's for the 'more' pages?
#7I'm not sure how the patent relates to the question. The UI issue is that a user traverses to the 2nd or 3rd page of viewing, go reads some articles or whatnot, and then comes back to find that he or she cannot move onto the 4th page. It's frustrating.
Arc server stores closures on server (see the patent for the similar technique). Links include unique ids of these closures. Closures expire. This has been explained numerous times here on HN, see the search link in my different comment.
The part that confuses me is that 'this has been discussed before' is considered a valid answer, as opposed to say 'yes it's horribly broken and no-one is willing to fix it'. The site routinely fails to return results for links it generated just minutes before. How that is not considered a bug, on a site that represents forward thinking web development, mystifies me.
Re: Why does HN generate unique URL's for the 'more' pages?
#8Patent, shmatent. What currently exists SUCKS. How many users have to complain before someone gets a glimmer of a clue that MAYBE they should try ANYTHING ELSE.
Re: Why does HN generate unique URL's for the 'more' pages?
#9Earlier quoted context omitted.
Arc server stores closures on server (see the patent for the similar technique). Links include unique ids of these closures. Closures expire. This has been explained numerous times here on HN, see the search link in my different comment.
The part that confuses me is that 'this has been discussed before' is considered a valid answer, as opposed to say 'yes it's horribly broken and no-one is willing to fix it'. The site routinely fails to return results for links it generated just minutes before. How that is not considered a bug, on a site that represents forward thinking web development, mystifies me.
I think storing state on servers is always a bad idea. State should be stored in a cookie in the user's browser, letting him decide when it expires.
Re: Why does HN generate unique URL's for the 'more' pages?
#10Earlier quoted context omitted.
Arc server stores closures on server (see the patent for the similar technique). Links include unique ids of these closures. Closures expire. This has been explained numerous times here on HN, see the search link in my different comment.
The part that confuses me is that 'this has been discussed before' is considered a valid answer, as opposed to say 'yes it's horribly broken and no-one is willing to fix it'. The site routinely fails to return results for links it generated just minutes before. How that is not considered a bug, on a site that represents forward thinking web development, mystifies me.
I gave a valid answer to the question in the title: "Why does HN generate unique URL's for the 'more' pages?" I agree that it's broken.