suggestion: use oci-spec crate for oci spec types

[waynr]

Howdy! I've been working on implementing the server side of the distribution spec lately and have found https://github.com/containers/oci-spec-rs super useful in interpreting image and index manifests, descriptors, and manifest configs. The types match up to the spec definitions pretty well and even cover some territory missing in this repo's types.

My suggestion is to consider switching over to oci-spec in a future breaking changes release. I would even consider performing this refactor myself if the maintainers are open to it (and potentially some of the downstream dependencies if that makes the suggestion more palatable).

The reason I'm interested in this is that I have a couple future tools in mind that I think would benefit from the compatibility offered by shared types. For example:

• my registry implementation is built around a core set of traits that abstract away backend details; i could use oci-distribution to create implementations of these traits that enables my registry to act as a pull through cache, or even to duplicate content to downstream registries.
• tonight i'm working on a test data crate focused on referential integrity that i'll eventually push to https://github.com/waynr/portfolio; for my current use case i don't think i'll need to push the data via the distribution api (i can push it directly to my database) but in the future i want to re-use this test data crate to implement better server-side distribution conformance tests

Anyway, let me know if this is a contribution you'd be interested in in the future!

[thomastaylor312]

I am definitely not opposed to it, and as a maintainer of a large chunk of those downstream dependencies I don't mind either. It seems like those definitions already have some traction, so it sounds like it would mutually beneficial. The main requirement is that all the types are spec compliant. It looks like they are, but so long as they are, I wouldn't have an objection to using those types instead.

@flavio should weigh in as well as he is the other active maintainer here

[flavio]

I welcome this proposal!

[jvanz]

I had the same idea during I was working in a issue in the Kubewarden policy-evaluator. Can we start by using the image configuration spec in the function to get image manifest and configuration? :)

[thomastaylor312]

Yep, that would be a fine place to start