# Service Bindings mapping:

### Currently we have the following layout defined for all CNB services

platform
└── services
    ├── primary-db
    │   ├── metadata
    │   │   ├── connection-count
    │   │   ├── kind
    │   │   ├── provider
    │   │   └── tags
    │   └── secret
    │       ├── endpoint
    │       ├── password
    │       └── username
    └── secondary-db
        ├── metadata
        │   ├── connection-count
        │   ├── kind
        │   ├── provider
        │   └── tags
        └── secret
            ├── endpoint
            ├── password
            └── username

The `$VCAP_SERVICES` json object looks like the following:

{
  "elephantsql": [
    {
      "name": "elephantsql-binding-c6c60",
      "binding_name": "elephantsql-binding-c6c60",
      "instance_name": "elephantsql-c6c60",
      "label": "elephantsql",
      "tags": [
        "postgres",
        "postgresql",
        "relational"
      ],
      "plan": "turtle",
      "credentials": {
        "uri": "postgres://exampleuser:[e-mail]:5432/exampleuser"
      }
    }
  ],
  "sendgrid": [
    {
      "name": "mysendgrid",
      "binding_name": null,
      "instance_name": "mysendgrid",
      "label": "sendgrid",
      "tags": [
        "smtp"
      ],
      "plan": "free",
      "credentials": {
        "hostname": "smtp.sendgrid.net",
        "username": "QvsXMbJ3rK",
        "password": "HCHMOYluTv"
      }
    }
  ]
}

The current `cnb2cf` implementation just copies `$VCAP_SERVICES` over to `$CNB_SERVICES`. We would need to take this code and translate it to a version that read `$VCAP_SERVICES` and write those values down on the filesystem as described in the CNB Service Bindings spec. Assuming that we translate those values correctly, the APMs which are already using the new spec should "just work".

The most difficult part of translating this from the `$VCAP_SERVICES` form to the CNB Service Bindings spec will be in determining the correct translation for `metadata.kind` and `metadata.provider`. The `$VCAP_SERVICES` bindings do not have equivalent fields. Instead, the matching was performed whenever a service binding name contained a fragment of the provider name. For example, the following `$VCAP_SERVICES` object:

{
  "something-newrelic-something": {
    "name": "newrelic-binding-c6c60",
    "binding_name": "newrelic-binding-c6c60",
    "instance_name": "newrelic-c6c60",
    "label": "newrelic",
    "tags": [
      "newrelic"
    ],
    "plan": "free",
    "credentials": {
      "token": "some-token"
    }
  }
}

would translate into the following file layout:

platform
└── services
    └── something-newrelic-something
        ├── metadata
        │   ├── kind     // contains "NewRelic"
        │   ├── provider // contains "NewRelic"? unknown, not clearly specified
        │   └── tags     // contains "newrelic"
        └── secret
            └── token // contains "some-token"

This means that we would need to maintain code that could perform the fuzzy-matching between "something-newrelic-something" and "NewRelic". We'd need these translations between all of the providers that we ship with all of the language families.