Remove distributed session delegation in order to clean up proc.ml #1172
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Channels are not innately suited to distributed computation because of the 'distributed delegation' problem which arises when sending channels over channels: if we send endpoint A over endpoint B, then we don't know where to route any messages to endpoint A.
Before, there was a ton of complex code which may or may not have worked, which attempted to implement a version of the distributed delegation algorithm described in the original Session Java paper. This significantly complicated the distributed sessions runtime in proc.ml and jslib.js.
In practice, we only really delegate from server to client, which does not require any special treatment. None of our present code sends session endpoints from client to other client, or client to server. Therefore, all of this spaghetti code is actually redundant. This patch removes all the distributed delegation code and therefore vastly streamlines the distributed session runtime. Attempting to do distributed delegation from client to server, or client to other client, will now result in a runtime error.
In future we may want to re-enable a form of this. I think the easiest way of doing this would be to explicitly allow the creation of "remote channels" whose buffers reside on the server with sends / receives requiring a remote call -- we would then only need to do name passing.