Elements and components; components and properties; properties and transmitters; transmitters and quanta; quanta and components; components and components; components and transmitters; transmitters and Elements; Elements and properties; properties and components... crikey

This blog entry is about Clique Space (TM) implementation progress.

It's been a while since my last post. I've been working hard on the implementation; working on replacing the precis and the projection mechanisms with a mechanism I hope will be able to be used by both Agent Devices and View enabled devices like the administrator client. Every time I feel I'm getting a handle on the implementation, I seem to stumble onto a new phenomenon which, upon closer inspection, appears to open up a set of hitherto unanticipated set of implications. I shake my head when this happens repetitively; I hope I am sufficiently sane to carry this proof-of-concept to some type of a demonstrable conclusion within the next year or two.

So, to the deliberation at hand...

The Element - component relationship is recursive, and different components can be represented to an Element as a mandatory scalar (the Element's identifier), an optional scalar (a Connection's Media Profile), or even as members of a set (an Identity's Connections). Properties promise to allow a device to manage its knowledge of Elements. The properties mechanism enables the separation of Elements from the Elements' components. This has one particular advantage: an Element, who's components can be naturally categorised into properties, can be implemented as a set of properties. The properties mechanism hence promises any device a relatively simple and reliable way to manage the device's knowledge of an Element's state and life-cycle.

Travelling along this line of rationale warranting the properties mechanism, I encountered some problems. How does one transmit an Element's components? What if Limiting Constraint affinity prevents partial transmission of a collection of components contained in a property? What type of complex logic would permit a "property changed" message to be transmitted? Can we just get away with a binary "component added" and "component removed" logic?

Additionally, I realised that I could simplify the implementation of the properties mechanism if I were to permit a general relationship between a property and its component(s): whether scalars or sets, properties can have a default collection relationship to an Element's components. This default collection aspect of properties is convenient for the requirement that Elements contain a set of properties, but it also compounds the problem of transmission.

So, an Element is a container of properties. Properties are a mechanism that categorises an Element's components. Properties may have a mandatory or optional singular (scalar) or set (or even, perhaps associative map) relationship with the components they categorise, but, to allow all properties a single way to access their components, all properties extend a base property class which contains an associative map of components. Hence, in this relationship, it appears necessary to acknowledge a pattern underlying the properties mechanism: an Element is a collection of collections of components.

This answer appears to have underscored the need to answer the question of component transmission with perhaps another mechanism. To do this, it appears convenient (if not absolutely necessary... but I think it is this too) that components, whether existing in a property as a scalar or as a member of a collection, are transmitted from one device to another, as singular pieces of atomic information, or to perhaps without warrant, steal a term from physics: quanta. The answer regarding the question of binary logic appears to be that we can get all we need simply by implementing add and remove logic; no change logic is necessary.

So, the solution to the question of property transmission...

A transmitter is an algorithmic vehicle which contains a quantum. A quantum may be a property's component if the component is a data type capable of serialisation, or it may be a serialisable copy of the component if the component cannot itself be serialised. One, and only one quantum is transmitted in a transmitter; a quantum represents the minimum amount of information representing a particular component.

So, why the transmitter? Can't a device just transmit and receive quanta? The answer is that the transmitter appears to use something akin to the visitor OO design pattern so that a device can understand why the quantum was transmitted. The transmitter mechanism is an abstract class of which there are two concrete extensions: one to deal with component addition and the other to deal with component removal.

When the agent device receives the relevant transmitter extension, it calls a method declared in the base transmitter and implemented in the relevant extension which in turn calls the add or remove component method on the quantum, doing whatever is intuitive to create or remove the corresponding component on the Agent Device which has received the transmitter. Hence, the receiving device uses the power of polymorphism given to a quantum's implementation to determine how this quantum affects the state of the corresponding component on the Agent Device.

This solution appears to be the simplest available. Exceptions can be generated for any transmitters that attempt to add a component which the receiving device currently knows of, or to remove a component which the receiving device doesn't know of, which appears to be almost all the questions of transmission answered. There lurk nearby, other phenomena which I have admired from afar; these phenomena appear to suggest other puzzles, but I'm hoping these puzzles are easier to solve.