Comments on: Continuations, cont’d

By: links for 2006-06-01 at protocol7

links for 2006-06-01 at protocol7 — Thu, 01 Jun 2006 12:21:03 +0000

[...] Continuations, cont’d (tags: continuations REST web to:read by:david_megginson) [...]

By: M. David Peterson

M. David Peterson — Sun, 21 May 2006 22:34:59 +0000

“replace the history stack” should be “replace the first item in the history stack” using a FIFO style method.

By: M. David Peterson

M. David Peterson — Sun, 21 May 2006 22:33:15 +0000

Now this is the kind of article I can stand behind Well stated David!

One additional piece of “workflow management”. It can be a bit controversial because it changes the state of the back button to something the user is not expecting. However, when there are situations where you are half way through a transaction, of which hitting the back button would have negative impact, sometimes there’s just no other way.

What I’m refering to is document.replace, which will replace not only the current document, but will replace the history stack with the same URI, so hitting the back button, in essence, takes you to the same place you are already at, and hitting it twice takes you to the beginning of the transaction (if used correctly.)

By: david

david — Sun, 21 May 2006 20:21:16 +0000

Dilip: thanks for both references.

By: Dilip

Dilip — Sun, 21 May 2006 17:35:54 +0000

Joe Duffy has a post with greater technical depth here:
http://www.bluebytesoftware.com/blog/PermaLink,guid,db077b7d-47ed-4f2a-8300-44203f514638.aspx

By: John Cowan

John Cowan — Sun, 21 May 2006 16:10:58 +0000

The problem with continuations on the Web is where to store them. Since we don’t have (and never will have) a distributed garbage collector for the Web, we don’t know when it’s safe to discard the continuation.

There are four possibilities:

1) Store the continuation in the URL. This is perfect if you can make it small enough to fit within the constraints of usable URLs.

2) Store the continuation on the server and use the URL as a key to find it. The difficulty here is that you have to throw these away eventually or the server runs out of space. When is it safe to discard the continuation? You have to guess. (Naturally, you mustn’t ever reuse such a key, but that’s fairly easy to arrange.)

3) Store the continuation on the client in a cookie. Same issue as #1, but less limited.

4) Store the continuation in hidden fields. The trouble with this is that in order to save, the user has to save the whole page, not just the URL. Most users aren’t used to that idea.

My best idea so far is a combination of #2 and #4. Store the whole page, complete with hidden fields, on the server and return an URL to it. People who bookmark the page will fetch it from the server and can carry on from there. Eventually the server will have to discard the page, after which bookmarking won’t work, but those who have been forethoughtful enough to save the page locally will still be able to carry on safely. Do your best to warn people of the necessity of
saving if they are going to leave the page for, say, a day (or whatever the server’s garbage-collection threshold is).

By: rps

rps — Sun, 21 May 2006 13:18:40 +0000

You don’t need to store all local variables, etc. With a newer innovation called delimited continuations, you can limit the extent of a continuation to a particular block of code. Things become both more clear and possibly more efficient. See

http://community.schemewiki.org/?composable-continuations-tutorial

And there’s no rule that says you can’t serialize continuations and put them in a hidden field on a client instead of on the server.

By: HREF Considered Harmful » Blog Archive » Ongoing Continuations

HREF Considered Harmful » Blog Archive » Ongoing Continuations — Sun, 21 May 2006 09:14:46 +0000

[...] There’s been some good discussion sparked by Gilad Bracha’s post on continuations, why they’re useful for web apps, and why the JVM still isn’t going to get them. In short, his argument is that although continuations do a very good job of modelling the kind of modal, sequential interactions we’re currently used to on the web, that kind of UI is a temporary (and unfortunate) anomaly and the age of modeless, multi-window, client/server style web applications is right around the corner - presumably ushered in by Ajax and friends. Disagreement with this takes two forms: Tim Bray thinks our current web UIs are just fine, thank you very much (they “are drastically constrained, offer a paucity of controls, and a enforce a brutally linear control flow; and these are good things), whereas David Megginson thinks continuations are drastic overkill even for those. My own thinking is somewhere in between. [...]

By: Dilip

Dilip — Sun, 21 May 2006 07:29:55 +0000

Ian Griffiths has more to say on that topic here:
http://www.interact-sw.co.uk/iangblog/2006/05/21/webcontinuations

By: david

david — Sun, 21 May 2006 00:52:57 +0000

Thanks for the comment, Aurynn. Here’s one way to think of it that might make you feel less dirty — you set up your action to receive a certain set of input parameters, and you set up the form so that the browser will submit that set of input parameters. Whether the parameters come from a user typing in a field or from static information stored inside the HTML document should be entirely an interface detail (in real life it’s not, unfortunately, because for error reporting your action has to know what fields can be corrected in a resubmission by the user, and which signal an internal error of some kind).

Personally, I prefer to use the URL over hidden fields when it makes sense. You can even post to a URL that has get parameters in a query string, but that’s probably getting too strange.