Replace old protection settings with the new persistent config description abstraction #66
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We want to be able to fake the entire protections manager without using a different class just by providing mock backends to all of the dependancies that do IO. We're now stuck and hesitating because we need to change the way we run intialization code in static methods ie the `create` methods. So yeah I want to do something about that, hopefully in a way that is not shit.
Problems: 1. Too many places are referencing TObject rather than `UnknownConfig` 2. The protection description uses the silly `registerProtection` utility rather than values directly that will aid type inference. 3. A lot of method signatures that accept a protection description are just wrong and don't make the protection description type generic, where we can do things like infer the type for capability set or the protection config.
Gnuxie
force-pushed
the
gnuxie/persistent-config-protection-settings
branch
from
c51ebaf to
38fe4b8
Compare
It really wasn't doing us any good when we had to use the mirror with an UnknownConfig.
Before it was asking for the entire PersistentConfigData adaptor which is kinda wrong
This helps when we can't change from one representation to another. E.g. Draupnir's command reader presentation types might be different to the JSON Transform decoder output type. So serializing allows them to be compatible. It kinda sucks but whatever.
Gnuxie
added a commit
that referenced
this pull request
Dec 9, 2024
I don't know why we were half asleep in #66. But set serialized value in this PR needs to be deleted.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When we decided to go with the config recovery in the safe mode work the-draupnir-project/planning#1, we also decided we would unify the wrappers used for all persistent config to be based on a system that leveraged TypeBox to provide us with schema. So this PR replaces
ProtectionSettingswith the newConfigDescriptionsystem. This branch was written and linked with the work to migrate draupnir's protection's to the new system too.This slightly longer because the types are not liberal enough in what they accept when they are describing interfaces. This is a general bitch throughout the code base and I don't really know how to address it yet.
Basically we need to allow interfaces for things like the methods on the
ConfigMirrorto accept arguments liberally. But the implementation needs to be as defensive asunknownetc. It's my fault for not really understanding variance properly.There was also an issue where the command reader from Draupnir's interface-manager produced objects that are different to the transform types in the
ConfigDescriptionschema. So we had to update theConfigMirrorto accept serialized representations of values as a workaround. Not a big deal but it's a thing.Aside from that I've been at a low point these past weeks.
the-draupnir-project/planning#35