The sift.json file
This is the definition file for your Sift. All apps must include one to be processed as Red Sift applications.
Structure
{
"name": "example-sift",
"display-name": "Example Sift",
"subtitle": "It will change your life",
"description":"This Sift processes a lot of data and makes it into an insightful indicator.",
"author": "You <[email protected]>",
"version": "1.0.0",
"marketing": {...},
"interfaces": {...},
"dag": {...},
"defs": {...}
}
Description of the top-level properties:
Field Name | Description |
---|---|
name | The name parameter needs to match the name of the Github repository containing your Sift. |
display-name | A user-friendly name for your Sift. |
subtitle | The subtitle to your display-name to be shown in the Sift Catalogue. Keep it short. |
description | The description to be shown in the details page of your Sift. On this one you can be more verbose. |
marketing | Marketing information (screenshots, source code URL, web page) for your Sift promotion. |
version | Semantic versioning of your Sift. |
interfaces | Entry points for the various user interfaces of your Sift (email, bots, ...). More details on its sub-fields below. |
dag | The computation DAG definition. This is highly configurable and the explanation warrants its own section in this documentation. |
Top-level parameter restrictions
The parameters above are the only ones allowed at the top level. Any attempt to add parameters at the top level will result in a validation error.
The "interfaces" field
The supported interfaces are defined below. They are all optional and in theory you could have an interface-less Sift but you probably want to choose at least one to display all the clever things your Sift is doing.
email | These are contextual interfaces for an email client and can be either an email thread or an email composer. You should specify the path to this view's controller implementation (see example below). |
summary | This is the most generic and ubiquitous user interface for a Sift. You should specify the path to this view's controller implementation (see example below). |
Example:
"interfaces": {
"email": {
"thread": {
"controller": "frontend/thread.js"
},
"compose": {
"controller": "frontend/compose.js"
}
},
"summary": {
"controller": "frontend/summary.js"
}
}
Your first example Sift created before contains no
interfaces
field initially, which is perfectly fine.
Naming restrictions
Property names starting with an underscore
_
is reserved for internal use. User defined keys starting with an underscore will not pass the validation.
Updated less than a minute ago