On Mar 3, 2016, at 11:21 AM, Bert Freudenberg bert@freudenbergs.de wrote:
Interesting:
Not just way back; HN uses continuations. (Not in many user-visible places any more, but every link on the front page used to be one—expired "next page" continuation links were a frequent source of grumbling.) Note that you don't have to expire continuations, necessarily—you could actually persist them statelessly (i.e. without server-side state), by shipping their encoded representations to the client embedded into HMAC-signed links. You're basically giving the server a raw bytecode-eval endpoint, and then making sure that it only accepts code you yourself wrote. Kind of a crazy strategy compared to the standard predeclared REST API, but interestingly flexible.
On Thu, Mar 3, 2016 at 11:54 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Interesting:
https://news.ycombinator.com/vote?for=11216194&dir=up&goto=item%3Fid%3D11212732
Not just way back; HN uses continuations. (Not in many user-visible places any more, but every link on the front page used to be one—expired "next page" continuation links were a frequent source of grumbling.)
Note that you don't have to expire continuations, necessarily—you could actually persist them statelessly (i.e. without server-side state), by shipping their encoded representations *to the client* embedded into HMAC-signed links. You're basically giving the server a raw bytecode-eval endpoint, and then making sure that it only accepts code you yourself wrote. Kind of a crazy strategy compared to the standard predeclared REST API, but interestingly flexible.
Yeah, it's pretty crazy. I actually implemented this in Altitude, (minus the encryption) and it works fine. Ultimately I that the security nightmare if somebody breaks the signing makes it too dangerous to actually use.
-Colin
squeak-dev@lists.squeakfoundation.org