Could you cryptographically sign the serialized form or something like that?
On Monday, February 22, 2021 at 8:59:29 AM UTC-8 [email protected] wrote: > On Sun, Feb 21, 2021 at 2:35 PM [email protected] <[email protected]> wrote: > > > > #lang web-server is brilliant. This #lang is, in my view, a really > excellent example of Racket's take on language-oriented programming. I find > that the performance of continuations is just fine, given my limited use of > them, and after a while you get used to the limitations and just program > around them. > > Thanks, a lot of people contributed a ton to it, specifically: Greg > Pettyjohn, John Clements, Joe Marshall, Shriram Krishnamurthi, > Matthias Felleisen. > > > > > One thing that always bothers me about #lang web-server, though, is that > there are a lot of provisos in the documentation. I'm talking about section > 3.2, "Usage Considerations", of > https://docs.racket-lang.org/web-server/stateless.html, in the part after > "However, there are some considerations you must make." Here a couple of > questions: > > > > + " [#lang web-server] will create an immense number of lambdas and > structures your program did not normally contain. The performance > implication of this has not been studied with Racket." > > > > This seems to me like an interesting research question. Has this > question been taken up? I've tried taking a look on Google Scholar for any > follow-up. I looked at citations of Jay's "Automatically RESTful web > applications" and "The two-state solution: native and serializable > continuations accord", but nothing stuck out to me (...which is not to say > that there may have missed something). > > > I never did any more research about this. I think you could take the > traditional Scheme benchmarks --- > > https://github.com/racket/racket/tree/master/pkgs/racket-benchmarks/tests/racket/benchmarks/common > --- and add `#lang web-server` to the top and see what happens. > > > > > + Some limitations of #lang web-server seem don't seem obviously > necessary, at least to someone who's not very familiar with the precise > details of the underlying program transformations. You get used to them, > but you wonder if there's some accessible world in which they work. For > example: "You may not use parameterize, because parameterizations are not > serializable." Is that inherently so (that is, there's no way around that, > no matter how clever you tweak the program transformations on which #lang > web-server rests), or is that just a conequence of the particular approach > taken (maybe it's possible, but no one has done it yet). Has there been any > fresh thinking about these limitations? > > In some sense, everything is possible, because we can just change the > way the VM works... the existing `#lang web-server` is designed to > never require modifications down there. In the case of `parameterize`, > the problem is a matter of security. Consider the following program: > > ``` > #lang racket > (define p (make-parameter #t)) > (define (launch-the-missiles!) > (when (p) .....)) > (define (run-code-downloaded-from-youtube f) > (parameterize ([p #f]) (f))) > ``` > > We don't want the code from YouTube to be able to launch the missiles. > Suppose that parameterizations were serializeable, then the YouTube > code could be something like: > > ``` > (lambda () > (call-with-parameterization > (read (with-input-string (hack-the-planet (with-output-to-string > (lambda () (write (current-parameterization))))) > launch-the-missiles!)) > ``` > > where `hack-the-planet` changes the `#f` to `#t`. That's why you can't > inspect parameterizations or enumerate the keys in a continuation mark > set. > > In general, all of the limitations of `#lang web-server` are because > of things like this. > > Jay > > -- > Jay McCarthy > Associate Professor @ CS @ UMass Lowell > http://jeapostrophe.github.io > Vincit qui se vincit. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/0854aacf-b390-4bc7-8b7a-6b114c19bb5cn%40googlegroups.com.
