-
Notifications
You must be signed in to change notification settings - Fork 282
Description
The TUF refactor aims at a more idiomatic use of OOP (see #1112). As such it seems reasonable to implement metadata entity behaviour as instance methods on the corresponding classes.
However, not all users of the metadata model need the same behaviour. For instance, a TUF client is likely to only need Metadata.verify and read access on all metadata object attributes, but none of the methods to modify attributes, which are needed by a repository library/tool, (e.g. sign, bump_version, bump_expiration, delegate, add_keys, add_targets, etc.).
This question about how to draw the line is especially important if unneeded functionality requires 3rd party dependencies, which we would have to vendor on a client.
Some possible approaches (brain storming):
- Use classes exclusively for attributes (except maybe for methods on sslib's
MetadataandSignedclasses, such assign,verify,canonicalise) and implement all behaviour on metadata user specific controller classes, e.g.Repository,Client(or something likeProject/Developer/Workspacefor PEP480. - Use Subclasses, e.g.
RepositoryTargets,ClientTargets, etc... - Expose all methods to all users of the model, but handle missing optional dependencies. E.g. raise something like an
UnsupportedLibraryErrorif a client callsMetadata.signbut does not have the underlying optional 3rd-party dependencies (see Revise extra dependency handling secure-systems-lab/securesystemslib#179)
Premise: Find a balance between OOP purism and pragmatism