The future of containers just keeps getting brighter and brighter.
Also notable is Docker isn't just containers, but they also have strong design opinions and container "philosophy".
Image ID
Each layer is given an ID upon its creation. It is represented as a hexadecimal encoding of 256 bits, e.g., a9561eb1b190625c9adb5a9513e72c4dedafc1cb2d4c5236c9a6957ec7dfd5a9. Image IDs should be sufficiently random so as to be globally unique. 32 bytes read from /dev/urandom is sufficient for all practical purposes. Alternatively, an image ID may be derived as a cryptographic hash of image contents as the result is considered indistinguishable from random. The choice is left up to implementors.It says:
>an image ID may be derived as a cryptographic hash of image contents
We just started the project last week and imported the original Docker v2.2, which this text is from, a few days ago. So, there is language that will change and improve before the initial v0.1.0 release.
The OCI membership includes important parties in the ecosystem from container engine implementers to public providers with container registries: Google, Microsoft, Amazon, Docker, CoreOS, Red Hat, and many others. This means that we have good a organizational setup to get a single industry standard. It is worth the additional effort to obtain that goal for the industry.
tl;dr appc is a source of inspiration for the OCI work and will continue to be maintained and available in rkt, Quay, and others. We have a good shot at an industry standard for container images. And we want to make that successful even if it requires some initial duplicated effort.
[1] https://github.com/opencontainers/image-spec#faq
[2] https://coreos.com/blog/making-sense-of-standards.html
(CTO of CoreOS, OCI Technical Oversight Board member)
>>Q: What happens to AppC or Docker Image Formats?
>>A: Existing formats can continue to be a proving ground for technologies, as needed...
Sounds pretty moribund to me. It exists only if it wants to be a proving ground, "as needed".
As an comparative example, we have common CSS specs which provide consistent support for most features as they are included, but Chrome, Mozilla, and WebKit are still able to experiment with new features.