How to handle non-unique catalog items?

[joelanford]

In #76 , we updated catalogd to prefix the names of Package and BundleMetadata objects with the metadata.name of the Catalog from which they are derived.

This solved the problem of making it possible to distinguish between these duplicate names, but it raises another question: Do we need mechanisms to help clients disambiguate? For example, the operator-controller project has an Operator API with spec.package which is expected to be a simple package name (e.g. etcd, not operatorhubio-catalog-etcd).

Does catalogd need to do anything here to help clients disambiguate or get a non-ambiguous view (e.g. maybe via filtering?)

[everettraven]

With the new storage and serving mechanism being introduced (see #113 #114 and #139 for more information), I think that this becomes a non-issue? Since we will be serving via HTTP on endpoints unique to each catalog there will be no need for a naming format of <catalogName>-<packageName> and it will be the responsibility of clients to fetch and handle the data processing to suit their needs.

I could be missing something, so is there any reason to keep this issue open?

[joelanford]

From catalogd's perspective (and with the proposed design), I agree that this issue is moot.

If we ever add an endpoint in catalogd that permits clients to make a single request that spans multiple catalogs (as @ncdc suggested in passing recently), we'll have to revisit this question.

[everettraven]

Closing this for now. If this comes back up we can re-open.