Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide on extent of OOP in metadata model #1133

Closed
lukpueh opened this issue Sep 10, 2020 · 2 comments · Fixed by #1229
Closed

Decide on extent of OOP in metadata model #1133

lukpueh opened this issue Sep 10, 2020 · 2 comments · Fixed by #1229
Labels
decision record Outcome of this discussion should be tracked in a decision record discussion Discussions related to the design, implementation and operation of the project documentation Documentation of the project as well as procedural documentation
Milestone

Comments

@lukpueh
Copy link
Member

lukpueh commented Sep 10, 2020

Should we create classes for dictionary attributes of inner metadata classes (Targets/Snapshot/Timestamp/Root)?

Con: Seems a bit over-engineered, removes the light-footedness that comes with Python dictionaries

Pro: Makes our use of OOP more consistent.
Why would we use classes for Metadata/Signed/Targets/Snapshot, etc. but not for the inner dicts? (see #1112)

Pro: Makes it easier to validate formats, if complex data structures are defined by classes and simple data types use type annotations. (see #1130)

@lukpueh lukpueh created this issue from a note in TUF refactor towards 1.0.0 (WIP) (Simple Metadata API) Sep 10, 2020
@lukpueh lukpueh changed the title Should we create classes for dictionary attributes of inner metadata classes (Targets/Snapshot/Timestamp/Root) Decide on extent of OOP in metadata model Sep 10, 2020
@lukpueh lukpueh added this to To do in TUF refactor towards 1.0.0 via automation Sep 10, 2020
@lukpueh lukpueh removed this from Simple Metadata API in TUF refactor towards 1.0.0 (WIP) Sep 10, 2020
@lukpueh lukpueh added the discussion Discussions related to the design, implementation and operation of the project label Sep 10, 2020
@lukpueh lukpueh added this to the Foundations milestone Sep 10, 2020
@lukpueh lukpueh added documentation Documentation of the project as well as procedural documentation decision record Outcome of this discussion should be tracked in a decision record labels Sep 10, 2020
@sechkova
Copy link
Contributor

Seems like up to now there is no better suggestion than implementing classes for metadata fields #1139 which can "self-validate" in a similar fashion as in-toto does (with its ValidationMixin #1030) and I think this type of validation is the strongest argument "for" classes.

Maybe wait until a suggestion of an implementation appears in #1139 so we can see it in practice? Meanwhile a brighter idea may come up 🤷

@lukpueh
Copy link
Member Author

lukpueh commented Nov 20, 2020

Thanks for reviving the issue, @sechkova. I also think that the metadata validation argument is very compelling. Because in order to validate the metadata schema, we need to define it in some way or another anyway, so we might as well use Python classes, which would also be useful for normal operations.

I can draft an ADR next week.

TUF refactor towards 1.0.0 automation moved this from To do to Done Dec 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
decision record Outcome of this discussion should be tracked in a decision record discussion Discussions related to the design, implementation and operation of the project documentation Documentation of the project as well as procedural documentation
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

2 participants