You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the implementation of our protocol is very rigid, allowing no parallelism between clients and server (though permitting limited parts of clients to run in parallel). This was the fastest (and safest) setup last time I checked, but perhaps for wrong reasons that are no longer relevant for newer GHCs and with the newer parallel GC implementation (9.2 improvements in particular) or can be sidestepped otherwise. I bet there is also some spurious complexity suffered to keep the protocol uniform in the absence of strong enough typing. I remember I had to avoid any (server-validated) multi-step UI interactions and express them instead as many disjoint non-modal steps with partial results saved in global state.
With the formalism, we'd be able to specify the permissible parallelism (e.g., who can do what after sending which message, e.g., if only receiving is permitted or also sending and of what messages exactly) and, within these bounds, experiment with various degrees of parallelism easily and safely and, later on, also extend the protocol.
@JamieFristrom: I have a hunch this may interest you. Let me know and I'd prepare groundwork. No hurry, obviously.
The text was updated successfully, but these errors were encountered:
Use the excellent formulation by @DavidEichmann from https://github.com/DavidEichmann/VersionedProtocolExample/blob/master/src/Core.hs. Simplify, for now, by not worrying about protocol versions, compatibility, migration, upgrades. When we go multiplayer over net, we'd need that, too. A good talk about the ideas in the simple setup, without versioning, is at https://skillsmatter.com/skillscasts/14633-45-minute-talk-by-duncan-coutts
Currently, the implementation of our protocol is very rigid, allowing no parallelism between clients and server (though permitting limited parts of clients to run in parallel). This was the fastest (and safest) setup last time I checked, but perhaps for wrong reasons that are no longer relevant for newer GHCs and with the newer parallel GC implementation (9.2 improvements in particular) or can be sidestepped otherwise. I bet there is also some spurious complexity suffered to keep the protocol uniform in the absence of strong enough typing. I remember I had to avoid any (server-validated) multi-step UI interactions and express them instead as many disjoint non-modal steps with partial results saved in global state.
With the formalism, we'd be able to specify the permissible parallelism (e.g., who can do what after sending which message, e.g., if only receiving is permitted or also sending and of what messages exactly) and, within these bounds, experiment with various degrees of parallelism easily and safely and, later on, also extend the protocol.
@JamieFristrom: I have a hunch this may interest you. Let me know and I'd prepare groundwork. No hurry, obviously.
The text was updated successfully, but these errors were encountered: