Meta-RFC: The future of Backends #2157
Conversation
This is an initial document trying to summarize the problem space around "backends" to try to help ground our future technical proposals in the existing context and to encourage us to "think ahead" to likely future changes so that we don't paint ourselves into a corner as we work iteratively. This document does not actually propose to write any code. Instead, it proposes to write some other RFCs that will in turn propose to write code. Signed-off-by: Martin Atkins <[email protected]>
|
Over in #2169 we had some discussion about the possibility of changing the state locking model to support both shared and exclusive locks, so that only state-modifying commands would take out an exclusive lock while state-reading-only commands could potentially run concurrently with one another. For the sake of this PR I think it makes sense to note that idea in the "state storage as plugins" section so we can prompt the author of the future RFC that defines the plugin API to consider whether to design the locking API to let the client specify whether it's intending to take out a shared or an exclusive lock, so that plugin developers will have the option of making use of that distinction if their target system can support it. (A remote system that cannot support shared locks could potentially just ignore that hint and always take out an exclusive lock, since that's the more conservative position.) |
This is an initial document trying to summarize the problem space around "backends" to try to help ground our future technical proposals in the existing context and to encourage us to "think ahead" to likely future changes so that we don't paint ourselves into a corner as we work iteratively.
Rendered Version
This document does not actually propose to write any code yet. Instead, it proposes to write some other RFCs that will in turn propose to write code. My hope in writing this is that we can design at least a few steps ahead of our implementation to allow us to work incrementally while maintaining a coherent vision of what end-state we're trying to reach.
Related feature requests:
cloudbackend #2238