User:Colin The Cat/Moduprint/API

Application Programming Interfaces are commonly used in computer software for communicating between programs. Moduprint is defining an API for interacting with the manager, other modules, and any other part of the print system. This API is based on Dynamic Impulses and Dynamic Variables.

Structure of a Module

A module is a Slot with the direct-binding Dynamic Variable Space "Module" defined on itself.

Dynamic Variables

Name	Type		Purpose
Module/ID	String	Required	Unique module identifier
Module/Version	uint3	Optional	Semantic Version (major.minor.patch)
Module/Name	String	Optional	Human-Readable name of the module
Module/ShortDescription	String	Optional	Human-Readable short description of the module
Module/ManifestOwner	String	Optional	Reserved for future use
Module/Lifecycle.Register	Slot	Optional	List of registry entries to create
Module/Lifecycle.Install	Slot	Optional	Dynamic Impulse on install
Module/Lifecycle.Uninstall	Slot	Optional	Dynamic Impulse on uninstall

The module ID is of the format Namespace.Module where Namespace is anything uniquely identifying the creator such as the user or group name and Module is the identifier of the module. Only one module with the same ID can be installed on the same manager at any point in time. The ID must only contain letters which are valid for a Dynamic Variable.

The registries are given as Slot children which each have a (not directly binding) Dynamic Variable Space on them as well as a dynamic Slot variable Target pointing to the registry entry.

Registries

Registries are the core system of Moduprint for communication between modules. A registry has a unique name and contains a list of entries. Every module can create an arbitrary amount of registry entries. Registry entries are just Slots with the name of the registry and a tag for priority.

Priorities

Name	Priority
Highest	-2.000.000
High	-1.000.000
Normal	0
Low	1.000.000
Lowest	2.000.000
Monitor	3.000.000

Instead of a priority name, a number can also be used directly as the tag. The monitor priority should only be used for event listeners which only check for the final data of the event without modifying it.

Registries are both used as a kind of dynamic list (for example for selection modes or packing handlers) and for registering event listeners. In the latter case, the registry entry should be a Dynamic Impulse Receiver with the Impulse tag and Slot name of the registry. High priority listeners are pulsed first (sorted by priority).

Calling Convention

A calling convention is commonly used by low level computer code such that functions can receive parameters and return results. The same is applicable to Dynamic Impulses. Moduprint uses the following convention for both sync and async dynamic impulses:

• If a function has no parameters, a regular impulse is used.
• If a function receives only one parameter, it is directly given as the impulse data.
• If a function receives more than one parameter, it receives a Slot as impulse data that has a Dynamic Variable Space defined on itself (not directly binding) with the parameters given as variables, which is referred to as the function's context.
• If a function returns data, it should write it into the localized (self-driven with write-back) dynamic variables Manager/Local.Result. If no variable of the correct type exists, the module needs to have one on itself as Module/Local.Result.