Skip to content
cloudspark edited this page Jan 29, 2014 · 33 revisions

Pods are federated containers which provide a range of function across a single domain of concern. For example, sending/receiving email would be part of the 'email' pod. Everything Facebook related would be in the 'facebook' pod etc. 'related' means things like authentication management : OAuth, or 3rd party API Tokens, namespaced data sources or file access separated from all other system concerns, contained and self-managed. The methods (actions/emitters) a Pod provides are instantiated via the API to create Channels.

Installing Pods

From server root :

npm install bip-pod-{pod name}
./tools/pod-install -a {pod name}

Pods are enabled in BipIO automatically during install by creating an entry in the pods section of your config file (config/{environment}.json. Depending on the pod you're installing, it may require further configuration, such as oAuth application keys etc.

Restart the server at your convenience.

Schemas

Pods are collection of similar actions (channels), and each action has its own schema. Schemas tell you a little about the capabilities of a pod and describe the attributes, imports, exports and configs any of its channels have.

Schema sample :

{
  "email": {
    "name": "email", // Pod Name
    "description": "Email", // Short Description
    "description_long" : "Email for Everybody" // Long Description
    "auth": { // Authentication requirements
      "type": "none", // none|issuer_token|oauth
      "status": "accepted", // Auth Status.  acceppted|required
      "_href" : "", // auth setup url,
      "scopes" : [], // oauth : Requested scopes
      "authKeys" : [], // oauth : Config keys
      "authMap" : { // issuer_token : username/password label map
        "password" : "API Token"
      }
    },
    "actions": { // action list
      "smtp_forward": { // actio name
        "description": "Send an Email", // Action Description
        "description_long": "Use to forward email messages to a chosen recipient", // Action Long Description
        "trigger": false, // Action is an emitter
        "singleton": false, // Action should be singleton
        "config": { // Channel Configuration Schema (JSON Schema)
          "properties": {
            "rcpt_to": {
              "type": "string",
              "description": "Email Address (eg: [email protected])",
              "optional": false,
              "unique": true,
              "validate": [ {
                "pattern": "email",
                "msg": "Invalid Email"
              }]
            }
          }
        },
        "renderers": { // renderer list
          "verify": { // renderer name
            "description": "Recipient Verify", // description
            "description_long": "Verifies this email channel recipient with a secret key sent to their inbox", // long description
            "contentType": "text/html" // response content type
          }
        },
        "exports": { // Channel Exports (JSON Schema)
          "properties": {
            "response_code": {
              "description": "SMTP Response Code"
            },
            "response_message": {
              "description": "SMTP Response Message"
            }
          }
        },
        "imports": { // Channel Imports (JSON Schema)
          "properties": {
            "subject": {
              "description": "Message Subject"
            },
            "body_html": {
              "description": "HTML Message Body"
            },
            "body_text": {
              "description": "Text Message Body"
            },
            "reply_to": {
              "description": "Reply To"
            }
          }
        }
      }
    }
  }
}

For attributes marked as JSON Schema (config/exports/imports), refer to (http://json-schema.org)

Singletons

For some Channels, it makes no sense to have two instances of the same kind present at any time. These channels are marked as singleton. The system doesn't prohibit multiple instances of singleton's, but use this flag as a guide when creating channels in an automated fashion

Describing Pods

To determine which channels are available for a pod, use the rpc

GET /rpc/pod/describe/{pod name}

Channels are created by pointing their action attribute to {pod name}.{action name}. For example, email.smtp_forward :

How To Find an Action

Authentication

To use a Pod with a 3rd party provider, and in particular with the case of OAuth, you will need to register your application with the provider so that users can authenticate their accounts for use in your system. ClientID's/Secrets and Callbacks for apps are defined in the config file under the appropriate config section for a pod.

OAuth

To start the server side oAuth process for an account needing to use a Pod, the client must call :

/rpc/oauth/{pod name}/auth

Its best to start this process from within a browser.

Issuer Tokens

'Issuer Tokens' are an abstraction which take a username and/or password for storage and re-use against a single account.

Creating Pods

A boilerplate sample is contained in the bip-pod repository for reference. This will be updated with more complex examples and can act as a working tutorial for building your own pods.

Clone this wiki locally