-
Notifications
You must be signed in to change notification settings - Fork 117
Pods
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.
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.
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)
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
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
:
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.
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' are an abstraction which take a username and/or password for storage and re-use against a single account.
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.
Core
Tutorials
Cookbook
- Example Bips
- Email Repeater
- One Time Email Receive
- Email Repeater With Template
- Email Repeater, Dropbox Attachment Save
- Email To RSS
- Web Hook to FB&Twitter
- One Time Message Serve
- RSS Atom Subscribe
- Twitter Followback
- SoundCloud oEmbed (native) Feed
- SoundCloud oEmbed (embedly) Feed
- Instagram Media Sync to Dropbox
Modules
Extras