CDMI Extensions - Container/Data Object Representations

[dslik]

In some systems, containers can have values. We should defined a standardized way to manage this.

E.g. allowing Accept: application/cdmi-object in addition to application/cdmi-container

[dslik]

The old proposal was that we use representations to allow any given path to be accessed as both a cdmi-container and a cdmi-dataobject. "container/data duality"

Currently, we define that it is an error to access a data object where the path ends in "/" and it is an error to access a container where the path does not end in a "/". If we relaxed the first restriction, containers could also be accessed as data objects.

E.g. A container called "/foo/". If this is treated as a data object, it would initially be empty, but you could add data.

"/foo" and "/foo/" are two different objects.

We would need to evaluate the spec to see where there are assumptions or specific stipulations about about the meaning of "/" in an object name.

[dslik]

First working session minutes recorded here: https://github.com/SNIA/CDMI-spec/wiki/Minutes-2022-01-26

[dslik]

This work is being incorporated into #283, since S3 objects named "/" can have a value, and S3 objects name "a" can have children.