Pebbles themselves are self-contained hardware or software objects that fulfill a certain task. Examples are a numeric entry keypad, an electronic piggybank or a speech recognition engine. Our vision is that all such devices shall, in the future, share a common middleware and reflection API.
A pebble that is compatible with the Pushhlogic/Tuplecore system is defined formally here. The XML schema for such a Pebble follows exactly the same structure.
An uninstantiated_pebble is a quad of a type_name, pebble_dataplane and pebble_behaviour.
A type_name is a string that is unique name for an uninstantiated pebble. It is sensible to use use URI's as type_names, since these can ensure uniqueness, but other mechanisms can also be used.
A pebble_dataplane is a set of (field_name, field_domain, field_type, field_value) quads where the field_names are disjoint.
A field_name is a list of strings. The last string is the final_field_name and the and others are tuple_names. By convention, field names are in lower cases and tuple names are capitalised (first letter is a capital letter). Field_names that are only different in their final_field_name are said to be part of the same tuple. Using Pushlogic, field_names are written with a hash sign between each string, for instance Pebbles#Lamp#status.
A field_domain is a disjoint union of safe and unsafe lists. Each member of the safe and unsafe list is a field_domain_specifier. A field_domain_specifier is a string constant or an integer, an integer range or an ellipsis. (Please see §5.7 for the concrete syntax for field declarations used in Pushlogic.)
A field_type is one of the following values (fluent, event, read_only, lock, money). Most pebbles only use the fluent type for all fields. A fluent is a conventional variable that retains its most-recently-written value and returns this value when read.
A field_value is a constant string that conforms to the field_domain. It is set to the first item on the safe list when the pebble is first created or reset. A field value may be interpreted to have integer or real semantics in some contexts, but it is primarily a string. (There is no NULL string but the string of zero length is allowed. When interpreted as a boolean, all values are true except for "", false, FALSE and 0.)
An instantiated_pebble is the conjunction of an instantiated_pebble and an instance_name.
The instance_name is a globally unique list of strings of which the first may generally be a URI string (ie has the prefix 'tup:').
The field_names of an instantiated_pebble are logically assimilated into the global address space by prepending the instance_name.
The pebble information (metainfo) for a pebble is held as part of the pebble_dataplane as fixed-value fields with pre-assigned field names whose first element is 'info'. Therefore there is no specific part of the pebble XML schema that corresponds to metainfo. These fields have read_only type; their domain safe list consists of a single string that is identical to their fixed-value; their unsafe domain list is empty.
Most of the metainfo is missing until a pebble is instantiated, but the type_name should be present in the field with name Info#type.
Pebbles do not act on other pebbles but can have internal reactive behaviour in the form of various unilateral interlocks and releases. For instance, a hardware interlock may prevent a furnace control field to be set to ON if a thermal cutout field is registering OVERHEAT. This is an example of an interlock. An example of internal reactive behaviour would be if the pebble set its own furnace control field to OFF when the thermal cutout field is reading OVERHEAT. None of the internal reactive behaviour is allowed to set any field to an unsafe value or to prevent a field from being externally set to a safe value. (See also §4.6.3.) The internal reactive behaviour of a Pebble is described (currently) using Pushlogic rules, that have their own schema described §4.1.
An instantiated pebble sits on platform which is either an embedded system or server. In terms of registration and metainfo, platforms have the same structure as Pebbles and hence do not show up as an explicit structure in the XML schema.
A platform has a platform_name that is a globally unique list of strings of which the first might be a URI string (ie. has the prefix 'tup:').
For embedded system platforms, quite frequently, there is only one instance of a given pebble ever present on the platform and because all execution platforms have unique names, the plaform's name can be extended with the string `Pebbles' and then the pebble's type_name is appended on to that to form the unique instance name for the pebble.
For instance, we might have a platform called `tup://192.168.1.100' and a pebble type_name of `ThermalCutout' giving a pebble instance name of 'tup://192.168.1.100#Pebbles#ThermalCutout'.
The metainfo for this example pebble would be found at
tup://192.168.1.100#Pebbles#ThermalCutout#Infoand we would expted the following field to also have the value `ThermalCutout':
tup://192.168.1.100#Pebbles#ThermalCutout#Info#type
Where there are several pebbles of the same type_name on one platform, these must have intance names that differ somehow. For instance, the pusher platform just adds a decimal number on the end of the type_name.
tup://192.168.1.100#Pebbles#ThermalCutout0 tup://192.168.1.100#Pebbles#ThermalCutout1 tup://192.168.1.100#Pebbles#ThermalCutout2
Platforms also have metainfo. This is held using field_names that begin with the word Platform. One typical field for a platform is an IP address. For instance, we would expect the following field
tup://192.168.1.100#Platform#ipaddressto have value '192.168.1.100'
For instance, a bundle instance name might be
tup://192.168.1.100#Bundles#ClimateControl
and its metainfo would be stored in fields such as
tup://192.168.1.100#Bundles#ClimateControl#BundleInfo#version tup://192.168.1.100#Bundles#ClimateControl#BundleInfo#copyrightMessage
and its (Pushlogic) local variables are placed in
tup://192.168.1.100#Bundles#ClimateControl#Locals#var1 tup://192.168.1.100#Bundles#ClimateControl#Locals#var2