3 ms·

> You could apply encryption Or you could identify which bits of state actually matter and define a stable REST API, instead of identifying application state a

> You could apply encryption Or you could identify which bits of state actually matter and define a stable REST API, instead of identifying application state as "any state the interpreter could possibly be in" in an attempt to pretend that state doesn't exist. > But continuations/closures are a way to control state. No, they're a way to hide state. But state is integral to the experience of a web application. Hiding it is just a leaky abstraction (for the reasons pointed out above). > the server can still behave in a purely functional way You're going to have to explain how that makes this technique RESTful. Notably, if you store the continuation on the server, you're violating REST's statelessness requirement: https://en.wikipedia.org/wiki/Representational_state_transfer#Statelessness https://en.wikipedia.org/wiki/Representational_state_transfe... Rolling up all the system's state into a single URI whose underlying state cannot be modified violates the requirements that each URI represent a distinct resource which can be manipulated (i.e. changed) using standard HTTP verbs: https://en.wikipedia.org/wiki/Representational_state_transfer#Relationship_between_URI_and_HTTP_methods https://en.wikipedia.org/wiki/Representational_state_transfe... Once you have persistent data (say, flight details stored in a database), you lose cacheability, since each interaction with that data from a different source is via a different URI: https://en.wikipedia.org/wiki/Representational_state_transfer#Cacheability https://en.wikipedia.org/wiki/Representational_state_transfe... At least this technique is pure HATEOAS, so there's that: https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS I don't disagree that there are places within a web application where this technique makes sense. The one example of this technique which is always presented – a short-lived dialogue-based interaction with the user – is one of them. That particular state is sufficiently short-lived, and doesn't need to be cacheable or shareable with others, that pretending it doesn't exist is probably helpful in the long run. But I posit that in general, it's always a better architectural decision to explicitly identify your state (i.e., everything which you're keeping in a database or on disk) and minimize it.

amelius 7y ago
> in an attempt to pretend that state doesn't exist. I think you misunderstand continuations, as they are closures which often do contain state. In fact, they can be used to capture all of the state relevant to the session.
- colanderman 7y ago
  I understand continuations perfectly. It is exactly the "capturing all of the state relevant to the session" which is problematic. Implicitly grabbing your application's state – including the context of what code is executing, and all in-scope variable bindings, which is the only "state" in a purely functional server such as you surmised earlier – and wrapping it into an opaque blob to pass to a client is exactly what I mean by "hiding state". Failing to identify and define exactly what is the relevant state with which clients should interact is exactly what leads to issues with upgrades, scalability, and security. I'd have no problem with this technique if, instead of an arbitrary call/cc or what-have-you, the developer had to explicitly name the continuation, and specify and name which bits of state are relevant. This definition could then form the basis of a well-defined public-facing interface, for which application tooling could ensure smooth upgrades, for which security properties could be easily demonstrated, and for which more stringent persistence rules than heuristic-based garbage collection could be defined.
  - tshanmu 7y ago
    this is what serialisable continuations[0] provide. [0] https://docs.racket-lang.org/web-server/stateless.html#(part._.Serializable_.Continuations) https://docs.racket-lang.org/web-server/stateless.html#(part...
0x445442 7y ago
> But state is integral to the experience of a web application HTTP is a stateless protocol and the desire to maintain a state-full session on the server is why web applications are fundamentally broken, at least within the context of HTTP.
- colanderman 7y ago
  Right, which is why session state should be kept on the client, and why the client should manipulate application state (i.e., everything that lives in a database) using a well-defined RESTful interface. The approach in the OP seems to conflate these two types of state. The end result is application state without a well-defined client interface, and session state which is passed backed and forth to the server.
  - deleted 7y ago
    [deleted]
  - amelius 7y ago
    > The approach in the OP seems to conflate these two types of state. Nope, I'm just saying that continuations and REST are orthogonal.

amelius 7y ago

> in an attempt to pretend that state doesn't exist. I think you misunderstand continuations, as they are closures which often do contain state. In fact, they can be used to capture all of the state relevant to the session.

colanderman 7y ago
I understand continuations perfectly. It is exactly the "capturing all of the state relevant to the session" which is problematic. Implicitly grabbing your application's state – including the context of what code is executing, and all in-scope variable bindings, which is the only "state" in a purely functional server such as you surmised earlier – and wrapping it into an opaque blob to pass to a client is exactly what I mean by "hiding state". Failing to identify and define exactly what is the relevant state with which clients should interact is exactly what leads to issues with upgrades, scalability, and security. I'd have no problem with this technique if, instead of an arbitrary call/cc or what-have-you, the developer had to explicitly name the continuation, and specify and name which bits of state are relevant. This definition could then form the basis of a well-defined public-facing interface, for which application tooling could ensure smooth upgrades, for which security properties could be easily demonstrated, and for which more stringent persistence rules than heuristic-based garbage collection could be defined.
- tshanmu 7y ago
  this is what serialisable continuations[0] provide. [0] https://docs.racket-lang.org/web-server/stateless.html#(part._.Serializable_.Continuations) https://docs.racket-lang.org/web-server/stateless.html#(part...

0x445442 7y ago

> But state is integral to the experience of a web application HTTP is a stateless protocol and the desire to maintain a state-full session on the server is why web applications are fundamentally broken, at least within the context of HTTP.

colanderman 7y ago
Right, which is why session state should be kept on the client, and why the client should manipulate application state (i.e., everything that lives in a database) using a well-defined RESTful interface. The approach in the OP seems to conflate these two types of state. The end result is application state without a well-defined client interface, and session state which is passed backed and forth to the server.
- deleted 7y ago
  [deleted]
- amelius 7y ago
  > The approach in the OP seems to conflate these two types of state. Nope, I'm just saying that continuations and REST are orthogonal.