3 ms·

Disclaimer: I haven't looked at the source yet. My particular example was for browsing the thread list. Let's s/continuation/browse context/. You can generate

Disclaimer: I haven't looked at the source yet. My particular example was for browsing the thread list. Let's s/continuation/browse context/. You can generate exactly one browse continuation a minute, and hand that one out to everyone who visits the page during that minute. It contains the effective state for that continuation. So it's a little out of date... big deal. Let's say a browse context is 1 kilobyte (which can fit a list of several hundred IDs and scores). With 1 gigabyte of RAM, you can store 1.9 years worth of browse contexts.

palish 18y ago
"Browse contexts" would not be able to be stored client-side, so the server cannot hand one out to everyone who visits a page. The server hands out an ID that references a browse context that exists on the server. Each browse context must be unique if you're logged in (otherwise you would see News.YC from someone else's perspective). When a user is logged in, one browse context is generated per link-that-requires-a-browse-context. Each "reply" link references a new browse context each time a page is loaded, for example. So if there are 50 comments on a page, then there are 50 "reply" links, each of which references a unique browse context. (If you mouseover each reply link in Firefox, you can see the ID of its browse context in the status bar. If you refresh the page, each reply link then references a different, unique, server-side browse context.) So it's easy to see why this could get a little expensive. It's essentially a time-consuming optimization problem to get rid of the "unknown or expired link" error, at this point. And it is not hard to work around.
- jcl 18y ago
  Hmm... I notice, however, that the "reply" link takes you to a fairly similar page as the "link" link in the comment's header: both contain a reply box. The "link" link, however, doesn't contain a fnid in the URL -- just a REST-like comment id. I wonder if these fnid-less URLs avoid generating continuations? If so, perhaps we could drop the "reply" link entirely and just label the "link" link as "link/reply"? If I understand your explanation correctly, that would both eliminate the error for initial replies and dramatically reduce the rate that continuations expire when using other site features...
  - palish 18y ago
    Yes, you're correct. That would both eliminate the error for initial replies and dramatically reduce the rate that continuations expire when using other site features. Unfortunately, that would completely remove the ability to "reply". :) When a logged-in user loads a Hacker News page, the server must generate a unique set of continuations for that user (one per each link that requires a continuation.) In other words, if everyone shared the same set of continuations, everyone would see the exact same Hacker News. The username in the upper-right corner would be the same, everyone's comments would be tagged with the same username, etc. Does that make sense? So the "reply" link requires a continuation because you're adding a comment that's tagged with your username. But the "link" link does not require one because you're simply viewing a comment.
    - jcl 18y ago
      Did you click on the "link" link? It has a box and reply button just like the reply page. So removing the "reply" link wouldn't remove the ability to reply. I assume the inputs for the reply function are adequately captured by the URL (comment ID) and cookies (logged-in user) and thus don't require a continuation.
      - palish 18y ago
        Oh snaps son. I got burned. You're right, I didn't click on the "link" link and assumed that it was only for viewing the comment. I sincerely apologize.
        jcl 18y ago
        No problem. Now all we need is for PG to tell us why it won't work. :) It's obviously a slightly different user experience, since users that aren't logged in won't get prompted to register/log in when clicking on "reply".
        palish 18y ago
        Keep in mind that getting rid of the "reply" link continuation would make the "Unknown or expired link" error less frequent, but it wouldn't solve the core issue of "each user requires a unique set of continuations". It would be a good stopgap measure in the meantime, though.
- jganetsk 18y ago
  I'm not trying to solve every problem. I'm just trying to solve browsing the list of threads. So, I'm not talking about reply. I'm not talking about links. Just giving me the main list of threads, that's why I wanted to call it "browse context". Not "reply context". I also do not suggest sending the "browse context" to the user. I'm suggesting sending an ID to the user, while the server can store up to 1.9 years worth of browse contexts, so that I can hit reload on the main page for up to 1.9 years without seeing an expiration. I would solve issues with reply separately. Maybe HN is meant to just be a demonstration of the power of continuation-based web dev.

palish 18y ago

"Browse contexts" would not be able to be stored client-side, so the server cannot hand one out to everyone who visits a page. The server hands out an ID that references a browse context that exists on the server. Each browse context must be unique if you're logged in (otherwise you would see News.YC from someone else's perspective). When a user is logged in, one browse context is generated per link-that-requires-a-browse-context. Each "reply" link references a new browse context each time a page is loaded, for example. So if there are 50 comments on a page, then there are 50 "reply" links, each of which references a unique browse context. (If you mouseover each reply link in Firefox, you can see the ID of its browse context in the status bar. If you refresh the page, each reply link then references a different, unique, server-side browse context.) So it's easy to see why this could get a little expensive. It's essentially a time-consuming optimization problem to get rid of the "unknown or expired link" error, at this point. And it is not hard to work around.

jcl 18y ago
Hmm... I notice, however, that the "reply" link takes you to a fairly similar page as the "link" link in the comment's header: both contain a reply box. The "link" link, however, doesn't contain a fnid in the URL -- just a REST-like comment id. I wonder if these fnid-less URLs avoid generating continuations? If so, perhaps we could drop the "reply" link entirely and just label the "link" link as "link/reply"? If I understand your explanation correctly, that would both eliminate the error for initial replies and dramatically reduce the rate that continuations expire when using other site features...
- palish 18y ago
  Yes, you're correct. That would both eliminate the error for initial replies and dramatically reduce the rate that continuations expire when using other site features. Unfortunately, that would completely remove the ability to "reply". :) When a logged-in user loads a Hacker News page, the server must generate a unique set of continuations for that user (one per each link that requires a continuation.) In other words, if everyone shared the same set of continuations, everyone would see the exact same Hacker News. The username in the upper-right corner would be the same, everyone's comments would be tagged with the same username, etc. Does that make sense? So the "reply" link requires a continuation because you're adding a comment that's tagged with your username. But the "link" link does not require one because you're simply viewing a comment.
  - jcl 18y ago
    Did you click on the "link" link? It has a box and reply button just like the reply page. So removing the "reply" link wouldn't remove the ability to reply. I assume the inputs for the reply function are adequately captured by the URL (comment ID) and cookies (logged-in user) and thus don't require a continuation.
    - palish 18y ago
      Oh snaps son. I got burned. You're right, I didn't click on the "link" link and assumed that it was only for viewing the comment. I sincerely apologize.
      - jcl 18y ago
        No problem. Now all we need is for PG to tell us why it won't work. :) It's obviously a slightly different user experience, since users that aren't logged in won't get prompted to register/log in when clicking on "reply".
        palish 18y ago
        Keep in mind that getting rid of the "reply" link continuation would make the "Unknown or expired link" error less frequent, but it wouldn't solve the core issue of "each user requires a unique set of continuations". It would be a good stopgap measure in the meantime, though.
jganetsk 18y ago
I'm not trying to solve every problem. I'm just trying to solve browsing the list of threads. So, I'm not talking about reply. I'm not talking about links. Just giving me the main list of threads, that's why I wanted to call it "browse context". Not "reply context". I also do not suggest sending the "browse context" to the user. I'm suggesting sending an ID to the user, while the server can store up to 1.9 years worth of browse contexts, so that I can hit reload on the main page for up to 1.9 years without seeing an expiration. I would solve issues with reply separately. Maybe HN is meant to just be a demonstration of the power of continuation-based web dev.