CDMI Extensions - CDMI Exports

[dslik]

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]

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]

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]

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]

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]

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

[dslik]

Proposal, restructure document to:

• Section 1 remains "CDMI Reference Model"
  • Clause 1 - 4 remain the same
  • Clause 5 becomes the "CDMI Object Model"
• Section II becomes "Exported Representations"
  • Clause 6 becomes "HTTP Data Object Exports"
  • Clause 7 becomes "HTTP Container Object Exports"
  • Clause 8 becomes "CDMI Data Object Exports"
  • Clause 9 becomes "CDMI Container Object Exports"
  • Clause 10 becomes "NFS Container Object Exports"
  • Clause 11 becomes "SMB Container Object Exports"
  • Clause 12 becomes "iSCSI Data Object Exports"
  • Clause 13 becomes "S3 Container Object Exports"
• Section III becomes "CDMI Advanced"

[dslik]

Rough draft of diagram to replace Figure 3:

This more clearly shows the separation of clients from protocols.