12 ms·

It usually isn't a big deal, because the fix -go back, copy, refresh the page, paste- is trivial. For a less technical audience, this would be absolutely unacce

by andreyf 19y ago

It usually isn't a big deal, because the fix -go back, copy, refresh the page, paste- is trivial. For a less technical audience, this would be absolutely unacceptable. Are there elegant solutions to fix this? Could someone link the explanation to how the continuation sessions work, please?

aston 19y ago
It's pretty similar to other session-based systems. Users get an id that they resubmit at some point to the server, and the server pulls the data associated with that id. In the case of Arc, that data is a closure (basically, a function and its bound variables).
bayareaguy 19y ago
I believe the specific code has to do with "fnid harvesting". See the comments here: http://github.com/nex3/arc/tree/master/srv.arc http://github.com/nex3/arc/tree/master/srv.arc line 330 or so. The general idea is described here: http://dresese.thehyatts.net/archives/000253.html http://dresese.thehyatts.net/archives/000253.html pg's original patent on this scheme: http://www.freepatentsonline.com/6205469.html http://www.freepatentsonline.com/6205469.html
rsheridan6 19y ago
Explanation: http://pagesperso-systeme.lip6.fr/Christian.Queinnec/PDF/www.pdf http://pagesperso-systeme.lip6.fr/Christian.Queinnec/PDF/www... A possible elegant solution is suggested in the paper: store the continuation on the client. I don't know what problems this presents in practice.
- nostrademons 19y ago
  With GET requests, you frequently run into URL size issues. IE has a roughly 1800 character limit, which is pretty easy to hit with machine-generated data. I remember going through hell with JSF charting frameworks, trying to squeeze the serialized data down under 1800 characters. Eventually we gave up, pulled everything out of the serialized data (it still took up over 1K though, just through framework metadata, and so only left us around 500-800 bytes to play with), and threw it into query parameters that we could control ourselves. This isn't an issue with POST, but then you run into the normal POST issues with refreshability, bookmarkability, and portable URLs.
- jcl 19y ago
  I would imagine that serializing your server's execution state to the client would require some pretty careful sandboxing to avoid security problems.

by andreyf 19y ago

aston 19y ago

It's pretty similar to other session-based systems. Users get an id that they resubmit at some point to the server, and the server pulls the data associated with that id. In the case of Arc, that data is a closure (basically, a function and its bound variables).

bayareaguy 19y ago

I believe the specific code has to do with "fnid harvesting". See the comments here: http://github.com/nex3/arc/tree/master/srv.arc http://github.com/nex3/arc/tree/master/srv.arc line 330 or so. The general idea is described here: http://dresese.thehyatts.net/archives/000253.html http://dresese.thehyatts.net/archives/000253.html pg's original patent on this scheme: http://www.freepatentsonline.com/6205469.html http://www.freepatentsonline.com/6205469.html

rsheridan6 19y ago

Explanation: http://pagesperso-systeme.lip6.fr/Christian.Queinnec/PDF/www.pdf http://pagesperso-systeme.lip6.fr/Christian.Queinnec/PDF/www... A possible elegant solution is suggested in the paper: store the continuation on the client. I don't know what problems this presents in practice.

nostrademons 19y ago
With GET requests, you frequently run into URL size issues. IE has a roughly 1800 character limit, which is pretty easy to hit with machine-generated data. I remember going through hell with JSF charting frameworks, trying to squeeze the serialized data down under 1800 characters. Eventually we gave up, pulled everything out of the serialized data (it still took up over 1K though, just through framework metadata, and so only left us around 500-800 bytes to play with), and threw it into query parameters that we could control ourselves. This isn't an issue with POST, but then you run into the normal POST issues with refreshability, bookmarkability, and portable URLs.
jcl 19y ago
I would imagine that serializing your server's execution state to the client would require some pretty careful sandboxing to avoid security problems.