Policies

Policies

Policies are a useful way to configure CENode instances (and their agents) with extra behaviour and functionality.

One of the primary uses of policies is to support network tasks and interaction between node instances using HTTP. Powerful configurations can be accomplished using policies in different ways. For examples, see section 5.3 of the CENode documentation.

Policies are declared as a child of the policy concept, which is included in the core model. In applications using policies, they can be included by creating instances of the appropriate type of policy.

In general, policies should be flagged as enabled by setting their enabled value to "true":

... and has true as enabled ... 

By default, policies act every few seconds, and can be added/removed/enabled/disabled at any time in the lifecycle of the agent.

tell policy

Tell policies instruct the local agent to forward tell cards addressed to the agent on to another agent at a remote URL.

Tell policies have no effect on cards that are not instances of tell card or that are not addressed to the agent on which the policy is active (i.e. using is to). Additionally, tell policies will only apply to tell card instances that have valid CE as their content attribute.

Set up a new tell policy on the local agent like this:

"there is an agent named agent2 that has '192.168.34.96:5555' as address"
"there is a tell policy named p1 that has the agent agent2 as target and has true as enabled"

ask policy

Ask policies instruct the local agent to forward ask cards addressed to the agent on to another agent at a remote URL. Often this is used in conjunction with a listen policy so that a response can be retrieved.

Ask policies have no effect on cards that are not instances of ask card or that are not addressed to the agent on which the policy is active.

Set up a new ask policy on the local agent like this:

"there is an agent named agent2 that has '192.168.34.96:5555' as address"
"there is an ask policy named p1 that has the agent agent2 as target and has true as enabled"

gist policy

Gist policies instruct the local agent to forward gist cards addressed to the agent on to another agent at a remote URL. Since gist cards typically don't result in responses from CENode agents, such a policy is usually setup to provide a one-way communication stream, however such a policy can be used in conjunction with a listen policy if a response is expected.

Gist policies have no effect on cards that are not instances of gist card or that are not addressed to the agent on which the policy is active.

Set up a new gist policy on the local agent like this:

"there is an agent named agent2 that has '192.168.34.96:5555' as address"
"there is a gist policy named p1 that has the agent agent2 as target and has true as enabled"

listen policy

Listen policies are a way for retrieving cards over HTTP sent to the agent on which the policy is active. The policy will avoid duplicating cards on the local agent and preserves the source of input CE.

Set up a new listen policy on the local agent like this:

"there is an agent named agent2 that has '192.168.34.96:5555' as address"
"there is a listen policy named p1 that has the agent agent2 as target and has true as enabled"

forwardall policy

Forwardall policies do not invoke communications between nodes - instead they simply re-map known tell cards in the agent's local KB.

In particular the policy causes the agent to re-address every tell card addressed to the agent to add each other known agent as a recipient.

For example, consider a local agent named agent1, which also knows about agents called agent2, agent3, and agent4. If agent1 receives a tell card, the policy will cause agent1 to add agent2, agent3, and agent4 as recipients of the card such that:

"there is a tell card named msg1 that is to the agent agent1 and has 'Hello, world' as content"

becomes something like

"there is a tell card named msg1 that is to the agent agent1 and is to the agent agent2 and is to the agent agent3 and is to the agent agent4 and has 'Hello, world' as content"

This policy used in conjunction with tell and listen policies mean that knowledge can be propagated through a network of CENode instance agents.

Other policies

Other policies do exist, but these will not be documented here. Take a look at the PolicyHandler class for help with this.

Add policies

If needed, policies can be added by modifying the PolicyHandler class. For this:

• Add a new handler function to the handlers array of the PolicyHandler class that performs the required logic.
• Conceptualise a new concept that has policy as its parent
• Create a new instance of the new policy concept
• If you need to use this on the web, re-build the library using npm run build-web