Having a single runtime API call to retrieve lots of information turns out to be a really bad idea, because any change to one of the fields (modification, adding, removing) will require a complicated upgrade process:
All nodes, which includes collators will need to have upgraded their nodes to understand the new format before we can upgrade the runtime to use it.
This is tedious, error prone (risks breaking parachains) and slow.
Instead if we had a separate runtime call for each of the fields:
- Adding new "fields" does not break anything.
- Modifying a "field" only affects code that actually queries it. If we have a runtime call that is only used on validators, collators don't need to upgrade.
- Removing a "field" is also easily possible: Just deprecate and stop using it and after some long enough time, you just remove it.
Ergonomics/performance:
Abstractions like RuntimeInfo and RollingSessionWindow can still be used and make the querying of individual "fields"/values as easy comfortable as it was before. By caching, performance will also not be problem. Especially because the individual fields are still only allowed to change once per session - so we only need to query them once for the duration of an entire session (as it used to be for SessionInfo too.)
Upgrade Path
SessionInfo is ubiquitous, as a first step I would adjust RuntimeInfo and RollingSessionWindow to be more generic and make it offer access to more runtime calls. Then any new "field" we will need in the future, will be its own call. This way the ergonomics of any other runtime api call should become the same as for SessionInfo.
Then we can introduce calls for all the fields in SessionInfo and make them mirror the values in SessionInfo. Eventually if everybody stopped using SessionInfo, we can remove it.
We can also be more relaxed and leave SessionInfo alone, but stop modifying it. Anything new we need, any modifications we need should be their own new runtime API call.
Implementation
As suggested by @rphmeier below. We should keep SessionInfo as an internal representation in the runtime, but it should no longer be exposed directly to the node.
Having a single runtime API call to retrieve lots of information turns out to be a really bad idea, because any change to one of the fields (modification, adding, removing) will require a complicated upgrade process:
All nodes, which includes collators will need to have upgraded their nodes to understand the new format before we can upgrade the runtime to use it.
This is tedious, error prone (risks breaking parachains) and slow.
Instead if we had a separate runtime call for each of the fields:
Ergonomics/performance:
Abstractions like
RuntimeInfoandRollingSessionWindowcan still be used and make the querying of individual "fields"/values as easy comfortable as it was before. By caching, performance will also not be problem. Especially because the individual fields are still only allowed to change once per session - so we only need to query them once for the duration of an entire session (as it used to be forSessionInfotoo.)Upgrade Path
SessionInfois ubiquitous, as a first step I would adjustRuntimeInfoandRollingSessionWindowto be more generic and make it offer access to more runtime calls. Then any new "field" we will need in the future, will be its own call. This way the ergonomics of any other runtime api call should become the same as forSessionInfo.Then we can introduce calls for all the fields in
SessionInfoand make them mirror the values inSessionInfo. Eventually if everybody stopped usingSessionInfo, we can remove it.We can also be more relaxed and leave
SessionInfoalone, but stop modifying it. Anything new we need, any modifications we need should be their own new runtime API call.Implementation
As suggested by @rphmeier below. We should keep
SessionInfoas an internal representation in the runtime, but it should no longer be exposed directly to the node.