Vault type-safety #6094
Vault type-safety #6094
Conversation
SanjoDeundiak
commented
Sep 26, 2023
•
SanjoDeundiak
commented
- Introduce more granular types for Vault
- Propagate these types to everything that was dependent on Vault
SanjoDeundiak
force-pushed
the
sanjo/vault_interface
branch
14 times, most recently
from
5ba314e to
454a50b
Compare
SanjoDeundiak
force-pushed
the
sanjo/vault_interface
branch
from
454a50b to
9801b93
Compare
implementations/rust/ockam/ockam_identity/src/purpose_keys/builder/common.rs
Show resolved
Hide resolved
implementations/rust/ockam/ockam_identity/src/purpose_keys/builder/credential.rs
Show resolved
Hide resolved
implementations/rust/ockam/ockam_identity/src/purpose_keys/builder/credential.rs
Show resolved
Hide resolved
| } | ||
|
|
||
| /// Return [`PurposeKeysRepository`] instance | ||
| pub fn repository(&self) -> Arc<dyn PurposeKeysRepository> { |
There was a problem hiding this comment.
If we move the implementation in CredentialsPurposeKeyBuilder and SecureChannelsPurposeKeyBuilder internal to PurposeKeysCreation I think we can remove:
repositorypurpose_keys_verificationsecure_channel_purpose_key_buildercredential_purpose_key_buildervault
This limits the possibility that these elements, in particular repository and vault are accessed via too many different code paths.
There was a problem hiding this comment.
Could you please elaborate?
There was a problem hiding this comment.
I'd rather enforce a separation between interfaces and implementations. If we create a struct with a certain purpose (no pun intended) like PurposeKeysCreation it should be able to do things via its public methods without have to expose its internals like repository or vault. Especially in the case of vault where we reach even further to use a more specific vault.
There was a problem hiding this comment.
Do you mean you would prefer to make those dependencies inaccessible outside of the structure?
SanjoDeundiak
force-pushed
the
sanjo/vault_interface
branch
from
9801b93 to
bb75eb1
Compare
