This page describes the basic concepts underlying IPAACA. For a theoretical background have a look at the research papers that were foundational to IPAACA's design:
For a short documentation of the command line tools that can be used with IPAACA, see IPAACA tools.
The basic unit of information transmitted (shared) in the ipaaca system is the Incremental Unit (IU), based on the "General, abstract model of incremental dialogue processing" by Schlangen et al. An IU is an object characterized by the following basic attributes:
IUs are persistent objects. That means that they can be modified at any time (unless specified as read-only by the user), and any changes of published IUs are automatically transmitted as updates to all relevant parties. They can also be modified from the remote side, unless specified otherwise.
The Message is a special case of an IU: it is a non-persistent read-only version of the IU. It can be used whenever you just want to send current information (akin to lightweight message-passing systems, hence the name), without the possibility of later modification. The benefit is that Messages are only present for the time of reception and do not occupy additional cumulative recources.
IUs are objects that exist in Buffers. A program can have any number of OutputBuffers and InputBuffers. When a new IU has been created, it has to be placed in an OutputBuffer. It is thereby published.
InputBuffers that components have initialized have a list of category interests, set by the user. Whenever an IU (or Message) of said categories is published or modified anywhere on the system, the corresponding InputBuffers will receive a notification of this, along with the updated IU contents.
Changes to IUs that are not marked as read-only can be effected at both ends of the pipeline: by simply writing to an IU present in a Buffer. When an IU has been written to from the remote side, the owner of that IU will also be able to receive a notification of this on the OutputBuffer where the IU was originally placed. IUs that have not yet been published can be written to at leisure without generating any events anywhere.
The actual contents of an IU are stored in its payload field. The payload is a key-value map, the contents of which are not mandated by the specification aside from the data format. Prior to protocol version 2 (Feb 2015), the payload was a string→string dictionary. Basic transport-layer compatibility with components using this older API is guaranteed. Starting at protocol version 2, the entries in the payload map are now JSON, enabling the use of lightweight structured objects.
The IU model offers the possibility of representing (light-weight) dependency networks for IUs. To this effect, ipaaca offers the links member of an IU, a map str→str. The keys inside the hash represent the link type (name), while the values are comma-separated lists of IU UIDs which represent the target IUs of outgoing dependency links of the present IU. For example, and as a reference convention, the "grounded-in" links ("grin") of an IU represent IUs upon which the data of the current IU is based. ( e.g. iu.add_links("grin", "uid-of-the-evidence-iu" ) )
IU
category: myCategory
uid: c4f74af9-ac0f-44d6-9b04-b9294930f9bb
owner: /ipaaca/component/MySenderIDd17eda72/OB
links: {"grounded-in": ['e2a40dc0-6337-4521-ba15-0e320116910f'] }
payload: {
"state": "DONE",
"resultList": [12, 24, 36, 48, 60],
}
In this IU, the payload map contains two entries (state and resultList). state is a JSON object of simple string type (directly compatible with older API versions). resultList is a list of integer values. Accessing these data is language dependent, descriptions can be found below.
There are Windows builds of the C++ version of IPAACA. Currently, two flavors exist: