Component Repository Specification needs clarification

[jensh007]

What would you like to be added:
This section is unclear to me. What is the goal here? And what kind of interoperability is the goal?

On one hand we say:
"This specification makes no assumptions and regulations about how Component Repositories will be implemented"
And then we describe a detailed protocol with functions and there parameters. This does not make any sense to me?

Either we are targeting some kind of interoperability between clients and server/repository. Then we need a full protocol spec. Or this is something internal and it should not be part of the spec.

Example: OCI image registry as backend. The interface is the OCI spec and this is enough.

Why is this needed:

[jensh007]

Similar is the local blob chapter:
Who should implement these functions and for what purpose and what kind of interoperability?

I suggest to rename this chapter to "Handling transports"

I think what we need here is a description of storage formats in OCI, maybe S3, etc.

Goal of the spec should be that anybody can implement a tool like OCM client purely based on the information of the OCM spec.

[achimweigel]

On one hand we say: "This specification makes no assumptions and regulations about how Component Repositories will be implemented" And then we describe a detailed protocol with functions and there parameters. This does not make any sense to me?

Either we are targeting some kind of interoperability between clients and server/repository. Then we need a full protocol spec. Or this is something internal and it should not be part of the spec.

Example: OCI image registry as backend. The interface is the OCI spec and this is enough.

This spec just described how the API of a Component Repo should look like. Because all Component Repos have the same API, a client could work with every Component Repo and it is not important how a particular Component Repo implements this API, i.e. if it stores the data in an OCI registry, a file system, a db or whatever. Of course we should/could extend the spec by defining more exact realisations of the API, e.g. a golang API, a http API etc. I think not every Component Repo must implement all realisations but if it implements one it should stick to the spec.

[achimweigel]

I also have my problems with respect to the local blobs. The motivation for these in the spec is either not clear enough or not convincing for me.

[jensh007]

Thanks Achim. If you look at the https spec section 1.3 describes the purpose of the spec followed by section 3, Terminology and Core Concepts From this it becomes clear what the spec is used for.

IMHO for OCM it should be possible for someone to:

• implement a client, processor, K8s controller, etc to access (read/write) a component descriptor at a central location.
• read/parse and/or write a component accessing the yaml parts, understand the semantics and ensure consistency

The second part is handled reasonably in the spec. But I am not sure about the first one. At least I don't get it.

[achimweigel]

I get it. It's about the motivation and yes we should include the points you listed here.