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?
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.
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).
Comments
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?
I believe the specific code has to do with "fnid harvesting". See the comments here: 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
pg's original patent on this scheme: http://www.freepatentsonline.com/6205469.html
Explanation: 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.
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.
I would imagine that serializing your server's execution state to the client would require some pretty careful sandboxing to avoid security problems.
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).