search

SNIA / CDMI-spec

Specification issues and source files
Other
3 stars 1 forks source link

CDMI Extensions - Container/Data Object Representations #248

Open dslik opened 4 years ago

dslik commented 4 years ago

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 commented 3 years ago

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 commented 2 years ago

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

dslik commented 3 months ago

This work is being incorporated into https://github.com/SNIA/CDMI-spec/issues/283, since S3 objects named "/" can have a value, and S3 objects name "a" can have children.