Compatibility between TEA and SCID

[ppkarwasz]

In package-url/purl-spec#516 @stevespringett proposed SCID as a new Package URL type for non-packaged software. For example:

pkg:scid/acme-industries.com/Acme/analytics-suite@5.2.1
pkg:scid/acmerobotics.org/Acme/robot-os@2.3.0

While a PURL doesn't necessarily need to resolve to a download location, this could be easily achieved if the company deploys a TEA service: the TEA Component Release object has all the data to properly find the download URLs of all the software distributions.

There are however a couple of aspects of the current draft that make it harded to use for a PURL type:

1. There is no way to find a TEA Component by name, which means that UUIDs would need to be used. This is far from ideal for readability:

   pkg:scid/acme-industries.com/Acme/0cde871e-90fd-474a-9a5f-69c142ecae5b@5.2.1
   

2. Component names are not guaranteed to be unique. Unlike products, components name are not decided by the marketing department, so the uniqueness constraint could be introduced.
3. Resolving a version number is a heavy operation, because /component/{uuid}/releases returns the whole and not paginated list of releases.

[ppkarwasz]

After a discussion on Slack, we should just make sure that given any PURL, we can efficiently retrieve the corresponding TEA Component Release.

Calling /componentRelease/{uuid} provides more metadata that any package ecosystem:

• URLs of distribution files,
• URLs of TEA Artifacts,
• Hashes and signatures of the above.

The main questions is how to resolve the TEA Component Release UUID in the smallest number of API calls.