SNIA / CDMI-spec

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

CDMI Extensions - CDMI Exports #296

Open dslik opened 3 months ago

dslik commented 3 months ago

Extend the exports system to include information on CDMI object access and CDMI path access. This generalizes the exports system to handle all possible access methods to a CDMI object.

An example of a CDMI object using this extension:

{
    "objectType": "application/cdmi­object",
    "capabilitiesURI": "/cdmi_capabilities/dataobject/"
    "exports": {
        "1": {
            "type": "HTTP",
            "URI": "/MyContainer/MyDataObject.txt"
        },
        "2": {
            "type": "CDMI ID",
            "objectID": "00007ED90010D891022876A8DE0BC0FD",
            "parentID": "00007E7F00102E230ED82694DAA975D2",
            "capabilitiesURI": "/cdmi_capabilities/dataobject/id/"
        },
        "3": {
            "type": "CDMI Path",
            "objectName": "MyDataObject.txt",
            "parentURI": "/MyContainer/"
        },
        "4": {
            "type": "NFS",
            "protocol": "NFSv4",
            "path": "/myexport"
        },
        "5": {
            "type": "S3",
            "BucketName": "Test",
            "BucketPath": "abc",
            "capabilitiesURI": "/cdmi_capabilities/dataobject/s3/"
        },
        "6": {
            "type": "RDMA",
            "id": "00007ED90010D891022876A8DE0BC0FD",
            "capabilitiesURI": "/cdmi_capabilities/rdma/read/"
        }
    },
    "domainURI": "/cdmi_domains/MyDomain/",
    "completionStatus": "Complete",
    "mimetype": "text/plain",
    "metadata": {},
    "valuerange": "0­36",
    "valuetransferencoding": "utf­8",
    "value": "This is the Value of this Data Object"
}

Where "1", "2", "3", ... are examples of user-specified keys naming each export.

dslik commented 3 months ago

The specification text for each export type should include documentation of the encoding of each of the export path/name/identifier/etc fields. If the encoding is dynamic or can change from object to object, the encoding for the object should be indicated as an export field.

When there are multiple versions of an export protocol, and the encoding of fields changes, should this be coupled with the version, or specified separately?

dslik commented 3 months ago

After a discussion about the best place for parentID, the consensus is that this should be grouped together with the other ID fields, especially given that ID support is optional. The example above has been updated to reflect this change.

dslik commented 3 months ago

For clarity, HTTP access is also an export (and could be at a different path), so this also fits into the generalized exports structure.

dslik commented 3 months ago

There are two different broad categories of capabilities: Capabilities that are intrinsic to the object (e.g. if the object is writable), and capabilities that are intrinsic to an access method. Currently, in CDMI, these are co-mingled in the capabilities object that each CDMI object refers to. If we add the ability to have a capabilities object reference to a export, then we can clearly differentiate between these two categories of capabilities, and keep they isolated from each other.

dslik commented 3 months ago

We need to clearly specify in normative text that the key for each export is a user-defined string.

dslik commented 2 months ago

Proposal, restructure document to:

dslik commented 2 months ago

Rough draft of diagram to replace Figure 3:

image

This more clearly shows the separation of clients from protocols.