Serialization vs. Manifest

[vbatts]

• The serialization.md shows a config json per layer, where the manifest.md only has one config json. What happens during translation here?
• The serialization.md shows file names for the objects, where the manifest.md just has the objects in a base-layer-first order.

[philips]

@vbatts who can help with this? What would your ideal be?

[stevvooe]

@vbatts The per layer approach should probably be dropped. Typically, Docker pulls these intermediaries up into "history".

The main question to be answered is whether images are built on other images or if they are a collection of layers. For performance and simplicity, the latter is better.

[vbatts]

The per layer approach should probably be dropped. Typically, Docker pulls these intermediaries up into "history".

Right. Which is lossy since it truncates down the config of the container that produced that image. If metadata like LABELs were not done with a Dockerfile, then that context is lost.

The main question to be answered is whether images are built on other images or if they are a collection of layers. For performance and simplicity, the latter is better.

I would say either. And given the mediaType, it can dereference it, but forcefully removing config per layer seems like an arbitrary assertion.
An image built can be built on top of, and still retain it's config, and be referenced as a dependency of child images.

[philips]

This feels like something we should sort out in v0.2.0. Can either @stevvooe or @vbatts take this one?

[vbatts]

@stevvooe what are your thoughts on https://gist.github.com/vbatts/870565ef6344f4a2b3b3f52fe4e51da3 ?

[stevvooe]

@vbatts That seems like the incorrect direction. It doesn't really make sense to have a manifest pointing to a combined object. The combined format is more just a container for image spec objects, where there may be one or more manifests. The actual relationships aren't between the combined object, but the objects referenced within. For example, whether or not the combined tar is one or two archives doesn't matter for the end result. It is just a package for shipping the contents.

[vbatts]

So part of this will be clarified with #94 and #95.
Though the notion of having having layered builds, or more like the "dependencies" notion from appc/spec.

[vbatts]

(sorry. Half a thought)
the notion of dependencies for building on a known CAS/fully-qualified-name, I haven't clarified this in my mind yet. I feel that this context is currently lost (or not straight-forward) with the current image specs.

[vbatts]

Closing this for a more articulate #102