Skip to content

How much metadata behaviour should be implemented on their classes? #1134

Closed
@lukpueh

Description

@lukpueh

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 Metadata and Signed classes, such as sign, verify, canonicalise) and implement all behaviour on metadata user specific controller classes, e.g. Repository, Client (or something like Project/Developer/Workspace for 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 UnsupportedLibraryError if a client calls Metadata.sign but 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    decision recordOutcome of this discussion should be tracked in a decision recorddiscussionDiscussions related to the design, implementation and operation of the project

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions