At 01:03 AM 2/3/2003 Monday, Avi Bryant wrote:
Seaside requires access to the entire context stack, but opaquely - it just needs to copy it, not to look at or change it. To put it another way, it needs access not to its caller's frame but to its own continuation, which seems reasonable to me from a security point of view (there was a brief mention earlier of a secured Scheme - did this still have call/cc?).
It's called W7 and is documented at http://mumble.net/jar/pubs/secureos/ . It's great. I strongly recommend reading it. It did have call/cc with indefinite extent continuations, which isn't technically incompatible with capability security. But indefinite extent continuations make it too hard to program defensively. Every caller has to worry that any callee may return to it multiple times. Jonathan Rees, who did W7, now agrees that default indefinite extent continuations are a disaster in the context of general caller/callee mutual suspicion. See http://www.eros-os.org/pipermail/e-lang/2001-July/005418.html for some related points.
Btw, call/cc with dynamic extent continuations are fine, as with Smalltalk's traditional "[:result | ^result]" .
It sounds like there's a genuine conflict here with Seaside, which we need to understand better.
---------------------------------------- Text by me above is hereby placed in the public domain
Cheers, --MarkM
On Mon, 3 Feb 2003, Mark S. Miller wrote:
Jonathan Rees, who did W7, now agrees that default indefinite extent continuations are a disaster in the context of general caller/callee mutual suspicion. See http://www.eros-os.org/pipermail/e-lang/2001-July/005418.html for some related points.
Btw, call/cc with dynamic extent continuations are fine, as with Smalltalk's traditional "[:result | ^result]" .
It sounds like there's a genuine conflict here with Seaside, which we need to understand better.
Seaside requires indefinite extent continuations to be able to properly model the interaction style inherent in web applications. Consider the common case of a web application putting up a form to gather information. In Seaside, the act of putting up that form is a method call, that will then block for user input. When the user submits, that method call will return with the values from the form. The pattern looks like this:
request := self respondWithForm.
So far, so good - it's an (extremely useful) inversion of the usual control flow of web applications, but it doesn't present any immediate problems.
However, say the user hits the back button and submits the same form, again. For the semantics to be consistent, this same method call must return, again, with a new set of values. Even if this were somehow implemented without using indefinite extent continuations, it would share the same problem: the caller has to be prepared to be returned to multiple times. This is fundamentally a property not of Seaside but of the existence of the browser back button.
For some papers on this approach, see
Paul Graunke, Robert Findler, Shriram Krishnamurthi, Matthias Felleisen, "Automatically Restructuring Programs for the Web" http://www.ccs.neu.edu/scheme/pubs/ase2001-gfkf.ps.gz
and
Christian Queinnec, "The influence of browsers on evaluators or, continuations to program web servers" http://youpou.lip6.fr/queinnec/Papers/webcont.ps.gz
squeak-e@lists.squeakfoundation.org
-
Avi Bryant -
Mark S. Miller