/**
 *
 * New and improved approach to context.
 *
 * Right now every node is configured and the context is
 * saved within the flow, at the node level.
 *
 * Advantage of this is, that when you remove a node the
 * context is automatically removed. But this is not how it should be.
 *
 * We will keep the context of the flow seperated and select
 * a current context for the flow.
 *
 * We could for example, always supply a test context.
 * We can play this context and the test version will run.
 *
 * This way, we have several configurations we can run the flow with.
 * This is much more powerful and seperates the flow from the context.
 *
 * How it is right now, is that function arguments are stored with the
 * function and then you can run the function without providing any
 * arguments, this is kinda useless... :-)
 *
 * We could also make this context message behave like a messenger.
 * This is a variant, in that case the context only contains the nodes
 * you want to visit. It will almost behave like actions. but differently
 *
 * The context then only contains the id's it knows about. It will
 * Does so in a sequential way. This could be done in stealth mode
 * If such a context visits a node and that node would trigger output
 * to someother node not in his list, that node will not be triggered.
 *
 * In non-stealth mode that node would be triggered and if it has all
 * It's input fullfilled it will start to run, that part of the flow
 * Will also run, although it's not in the list of the messenger.
 *
 * Then if you really wanna have fun, you could specify stealth per
 * node in the list, but that's for experts... :-)
 *
 * By default actions are in stealth mode, they trigger no side effects.
 * Context objects also are in default in stealth mode.
 *
 * Maybe later you can then also configure node's to detect stealth mode
 * and process anyway. This could be useful for logging for instance.
 * Or probably this detection should be on the port level.
 *
 * At the stage level, context will be saved in a higher level
 * context object. Ultimately we should be able to re-use
 * the test context from a flow, take each flows test context
 * and run the stage in test mode. Also at the stage level
 * we would want to select defaults for some flow and we do not
 * want to configure each and every flow by filling in it's form.
 *
 * However now what to do about actions? I think a flow that has
 * actions defined, is per definition a flow that will not be able
 * to run as a whole. it will not make sense.
 *
 * Providing context for the action level is easy, only problem
 * is where to store it? Saving context for the flow level is easy.
 * It belongs to the flow. I could save action context at the same
 * level, because it will just contain the nodes that matches
 * the nodes in the action. But it will be a loose coupling then.
 * I could save that context with stealth as default. Running
 * that context on the flow will behave just like an action then.
 * So this leaves the question, are actions correctly defined.
 * Right now an action is a set of nodes, nothing more.
 * An instruction is a set of nodes _with_ context.
 *
 * So basically an action defines the structure of a context set.
 * // message message
 *
 * Sooo, action + context = instruction
 *
 *  Instruction:
 *
 *   Action  = Throw ball
 *   Context = where: to the left
 *
 *  So, probably, the loose coupling doesn't matter.
 *  If I configured an entire flow and have that context saved.
 *  I feed that context to just one action, it will only perform
 *  that action. Only problem arrises with overlapping nodes.
 *  But I shouldn't worry a lot about that. Probably
 *  a graph with overlapping nodes that make by the creator
 *  will run as expected.
 *
 *  UI: context could be displayed like a node in the graph
 *  or it could be displayed as a list or something.
 *
 *  Clicking that context will show the edit form.
 *  The participating nodes could be highlighted, just like with
 *  actions. Non-existing nodes should be detected and removed.
 *
 *  Hm, it really is almost the same as actions.
 *  But actions are also defined to be able to run them from
 *  the programmatic api.
 *
 * Anyway what needs to be changed:
 *
 *   - Nodes do not carry their own context anymore.
 *     They only contain generic settings for that flow.
 *     Settings that cannot be changed by context.
 *     E.g. the expose is flow specific not context specific.
 *     persist is flow/link specific not context specific.
 *
 * Context doesn't modify the flow structure in any way.
 * Except from the stealth mode configuration.
 *
 *
 */
{
  "type":"object",
  "title":"Chiχ Context Object",
  "description": "A context object contains all context for a given map",
  "properties":{
    "key": {
      "type":"string",
      "required": true
    },
    "title": {
      "type":"string",
      "required": true
    },
    "description": {
      "type":"string",
      "required": true
    },
    "context": {
      "type":"object",
      "required": false
    },
    "ports": {
      "type":"object",
      "required": true,
      "properties":{
        "input": {
          "type":"object"
        },
        "output": {
          "type":"object"
        },
        "event": {
          "type":"object"
        }
      }
    }
  }
}