Closed wking closed 7 years ago
I just take basic learning on XDG Basedir Library
, and feel it is not a rule of ietf.org, and is not widely applied on internet server disign. I'm not sure if it is a good alternative to well-known uri.
... and feel it is not a rule of ietf.org, and is not widely applied on internet server disign. I'm not sure if it is a good alternative to well-known uri.
It would be a terrible alternative for publishers ;). Note that xdg-ref-engine-discovery.md
, unlike well-known-uri-ref-engine-discovery.md
, has nothing to say about publishers. There's no net access at all in the XDG spec. The XDG spec is a local config spec, and it's useful when you and/or your local sysadmin has opinions about resolving images. Those opinions should trump remote admin opinions, which is why oci-discovery
checks XDG ref-engine discovery matches before falling back to well-know URI matches. But the two specs are independent, so other consumers can mix and match as they see fit.
I've pushed b971df3 → 2a297c5 with a number of cleanups. I've also filed #44 with some of the preparatory work. I recommend we focus on #44 for now, and come back to this PR once we have that landed.
Rebased over the just-landed #44 with e5a218a → 4179e94.
I've pushed dc01602 → 3ac07d4 moving the types over to the XDG package and adding some XDG unit tests.
LGTM
This allows tools (like
oci-discovery
) to use local files to provide ref- and CAS-engine suggestions for arbitrary image names. Besides the general flexibility, this demonstrates the flexibility of the discovery approach and underscores the fact that the well-known URI approach is just one of many possible approaches.The commits running up to the tip are smaller pivots to setup for the new protocol. I can spin them out into their own PRs if you like, or break any of the commits up into even smaller pivots if that will help. If/when we land the Markdown spec for the XDG protocol, I'll file a separate PR updating the Python package.