On Sat, Oct 13, 2018 at 3:11 PM George Neuner <gneun...@comcast.net> wrote:
> The web-server language helps in conserving memory because its > continuations can be serialized - stored in files, or in databases, etc. - > and so the program's continuation state(s) can be persisted to disk rather > than memory as in a stateful #lang racket program. For that ability, the > program necessarily becomes a bit more more complicated (stuffers, etc.). > I would be interested to hear in what way you have found stateless `#lang web-server` servlets more complicated than stateful ones. That hasn't been my experience, though, as I said, I've used stateless servlets much more extensively than stateful ones. In particular, I haven't found stuffers a source of complexity at all. The only time when I've really had to fiddle with the stuffer at all is when there are security considerations and I need to guard against forged urls, but the process for doing that is easy and documented ( http://docs.racket-lang.org/web-server/stateless.html#(def._((lib._web-server%2Fstuffers%2Fhmac-sha1..rkt)._.H.M.A.C-.S.H.A1-stuffer))). In particular, the security consideration is fundamentally the same as for any RESTful web program: in fact, I would argue that customizing the stuffer is easier than trying to check against forged query parameters if writing an equivalent program manually. Still, there is probably room for improvement. Maybe `make-default-stuffer` could take an optional keyword argument to make it sign continuations with a given key? 1) The Racket program can read out all the results [freeing up the DB > connection], send the 1st page of 20 and include continuation links for the > additional pages. But there are 59 pages of results, plus <back> and > <forward> where applicable. Even limiting to, say 10 page links at a time > [like Google], that means 11 or 12 outstanding continuations kept open on > this one user session. AND, no good way to decide when to expire them ... > the user may go off and examine some result(s) for a while, then come back > to the list. > If I understand your example correctly, stateless servlets essentially let you write your program like #1 and transforms it into something more like #4 automatically, as long as your representation of search results is serializable. The data and context for all of the other page links are serialized as part of the continuation. If small enough, they are all sent over to the client; otherwise, their saved in hash-addressed storage and the client gets the hash to find them again. By default the hash-addressed storage just uses the filesystem, but you could easily adjust the suffer to use a database instead. Of course there are still design considerations, and stateless servlets don't eliminate those any more than manually RESTful web programming does. In particular, if the search results might change due to external events (e.g. the library purchases a new book), you have to decide what to do about that. > And cookies can be used to store user session state rather than encoding > it into URLs (continuation based or not). > Just a word of caution here that cookies may or may not be the right notion of state for a given application: sometimes you really want the semantics of "web cells" (see "Interaction-Safe State for the Web", http://scheme2006.cs.uchicago.edu/03-mccarthy.pdf and "Implementation and Use of the PLT Scheme Web Server", http://cs.brown.edu/~sk/Publications/Papers/Published/khmgpf-impl-use-plt-web-server-journal/paper.pdf). I will say that it took me several readings of these papers to get my head around the ideas well enough to use them, but there I still run into commercial web applications that use the wrong kind of state. -Philip -- 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
