The state only lives for a single RPC session.

When using WebSockets, that's the lifetime of the WebSocket.

But when using the HTTP batch transport, a session is a single HTTP request, that performs a batch of calls all at once.

So there's actually no need to hold state across multiple HTTP requests or connections, at least as far as Cap'n Web is concerned.

This does imply that you shouldn't design a protocol where it would be catastrophic if the session suddenly disconnected in the middle and you lost all your capabilities. It should be possible to reconnect and reconstruct them.

▲

crabmusket 4 days ago | parent | next [-]

Hmm so websocket reconnects could break state? Important to know when building on this, to e.g. re-establish the object graph when beginning a reconnected session? Or when using the http protocol is a possibility - to e.g. always include the "get object" as the first call in the batch.

	▲	kentonv 4 days ago \| parent [-]
		Yes, when you reconnect the WebSocket, the client will need to call methods to get new instances of any objects it needs. The old stubs are permanently broken. FWIW the way I've handled this in a React app is, the root stub gets passed in as a prop to the root component, and children call the appropriate methods to get whatever objects they need from it. When the connection is lost, a new one is created, and the new root stub passed into the root component, which causes everything downstream to re-run exactly as you'd want. Seems to work well.

▲

doctorpangloss 4 days ago | parent | prev [-]

^ maybe the most knowledgable person in the world about these gritty details

RPC SDKs should have session management, otherwise you end up in this situation:

"Any sufficiently complicated gRPC or Cap'n'Proto program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Akka"

▲

vereis 4 days ago | parent | next [-]

i think the original quote is "Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang" :-) but your point still stands

	▲	coryrc 4 days ago \| parent [-]
		Not quite :) https://en.m.wikipedia.org/wiki/Greenspun%27s_tenth_rule

▲

paradox460 4 days ago | parent | prev [-]

Isn't akka just a poor man's erlang