Another 9k walk brings about another turning of the Clique Space(TM) soil and another chance to massage the ideas put in the patent. Perhaps, another chance to cast these ideas into the realm of prior art.
This idea development concerns the purpose of the Account Profile with regard to the generation of a Participant for a certain Clique. Now, let's be fair. The Account Profile concept appears in the patent because I felt that the Limiting Constraints a Participant could take would mostly be conditional on the role that an Active Affiliation (now an Identity) would assume. A role (an Affiliation) is associated with a role hierarchy - an Account Profile hierarchy. Now, this is exactly the idea that I retain when I change the name of the Account Profile to the Mode Profile. This blog entry is merely a product of an opportunity I have had to think more about the detail of this mechanism. One should find little to surprise ones self when given more time to deliberate an idea, my idea appears to have become more complicated. Still, I assert that I have preserved the intent as it was given in the patent.
The change of the name is both a clarification on the structural relationships between the other Elements, and an acknowledgement about how the Mode (nee Account) Profile's purpose fulfils the objectives of the Clique Space concept especially in relation to Participant creation and destruction. This clarification also promises to widen other avenues of exploration: 1. how the concept of constraint compromise is asserted and accepted, and 2. how Cliques can be used as a means of conveying all manner of information about individuals; information that these individuals want others to know by virtue of the fact that one has a Participant as a member of a Clique. The second of these ideas may be deliberated in a future entry, but the first is covered somewhat below...
The term Mode Profile conveys a better structural meaning than Account Profile: a Clique's medium is shaped by its mode. A Clique's medium is specified by the flattened Media Profile hierarchy union of all the Participant's constituent Connections. A Clique's mode is similarly specified by finding the union of the flattened a Mode Profile hierarchy - specified by the Participant's constituent Affiliations. Because a Clique's mode must cover the Clique's medium, every parameter of each Media Profile's Enabling Constraint must be specified by no more than one Limiting Constraint value of a corresponding Mode Profile, and every parameter must be specified exactly once.
Hence, every Enabling Constraints' parameter in the flattened Media Profile which the flattened Mode Profile hierarchy describes must be covered once, and once only by the flattened Mode Profile hierarchy. Doing this creates a tightly coupled relationship between a Mode Profile hierarchy and the Media Profile hierarchy the Mode Profile hierarchy provides Limiting Constraint values for. However, I believe that the exercise of care in crafting Media and Mode Profile hierarchies should prove this coupling to be extremely versatile... we'll see...
The case may certainly arise where a role provider certainly does not intend to restrict the function of a device to some tightly constrained range of operational freedom. In these cases, the Mode Profile has two tools: the "unspecified" Limiting Constraint value, and an indicator showing whether or not a Limiting Constraint will permit compromise.
The unspecified value is intended to allow a Mode Profile to explicitly say that a Clique may exist in which values freely vary in one or more parameters. This Limiting Constraint value is compatible with any Enabling Constraint parameter. Relationships might be able to be set up between parameters so that specific parameters may be set to determine how other parameters may vary. For instance, one Clique may exist where values can vary, but only if all participants vary them to the same values in unison. Alternatively, a Clique may exist where Participants may freely vary one or more parameters to whatever value each Participant desired. Additionally, a Clique may exist where one or more parameters may specify a range of values that other parameters may freely vary within. Yet other Cliques may exist where parameters may depend on some relationship between other parameters, and control of them may be encoded in a Clique control algorithm specified in the Media Profile or left to the mechanics of the external devices' collaboration to moderate.
Whether or not a Limiting Constraint will permit compromise (also used in other internal Elements than merely the Mode Profile) is intended to be a way to allow a Participant's medium to acquire Limiting Constraint values which contradict the values given from two or more internal Elements. The compromise indicator has two values: deny and permit. This indicator asserted by one source, will permit Clique Space some ability to determine whether this source or another source contradicting the first source should be expressed in the Participant. Compromise needs to be taken into account when dealing with contradicting Limiting Constraints from the following competing sources: 1. a device in terms of a Connection or its constituent Media Profiles, 2. the individual in terms of an Identity or an Axle, 3. the provider of a role in terms of an Affiliation or its constituent Mode Profiles, and 4 as a Limiting Constraint with an unspecified source provided when the Participant is to be created. This compromise indicator is used in 1. a Mode or Media Profile in relation to a specific medium or 2. unrelated to a specific medium in another internal Element within the scope of an identity or to a Limiting Constraint with an unspecified source.
As briefly stated above, a Limiting Constraint permitting compromise may also permit overriding by a value given without an internal Element source at the time a Participant is created. The Participant, if created, is indicated as the source to these type of Limiting Constraints. In any case, if two or more Limiting Constraints describing the same parameter are found, and none of these parameters deny compromise, then the Clique Space will respond first by informing the individual associated with Identity through a connected View enabled device, waiting for a time specified by the individual requesting formation. If, in any case, two or more Limiting Constraints relating to the same parameter but from different sources deny compromise, then no Participant can be created. Hence, an Identity cannot provide two or more Limiting Constraint values for a single Enabling Constraint parameter which do not allow compromise; at least one must allow compromise.
These mechanisms allow a Clique's medium and mode to be as flexible or as
organised as the individual members might, by their membership of the Clique, permit. It would be interesting indeed to see a mechanism like this work.
Monday, October 29, 2012
Wednesday, October 24, 2012
Société Clique Space
Perhaps I illustrate the limits of my knowledge of the French language. C'est la vie...
Imagine that an individual within this world can determine which individual is responsible for every single bit of hardware and software - every device - one might come into contact with as one travels through life. Imagine an individual who can choose to ignore any device if they cannot readily determine who is responsible for a particular device. Imagine in this world, an individual who can record, in real time, the activity of any device one possesses, and can produce this device activity log as evidence of some interaction with other individuals at some future point in time.
This is Clique Space(TM). This concept uses the notion of constraints to provide a way for users to communicate mutual affinity between devices before these devices engage in a collaboration. Clique Space allows one individual to find any device possessed by an individual as easily as it will allow that individual to find an individual who possesses a device.
Technically, this mechanism exhibits many parallels with a nervous system. However, I am no authority on nervous systems, so my estimations on the similarity between Clique Space and a nervous system may be groundless, but I'd like that to be proven. My prototype is still incomplete, but I can now perhaps see what is left to be done.
Imagine that an individual within this world can determine which individual is responsible for every single bit of hardware and software - every device - one might come into contact with as one travels through life. Imagine an individual who can choose to ignore any device if they cannot readily determine who is responsible for a particular device. Imagine in this world, an individual who can record, in real time, the activity of any device one possesses, and can produce this device activity log as evidence of some interaction with other individuals at some future point in time.
This is Clique Space(TM). This concept uses the notion of constraints to provide a way for users to communicate mutual affinity between devices before these devices engage in a collaboration. Clique Space allows one individual to find any device possessed by an individual as easily as it will allow that individual to find an individual who possesses a device.
Technically, this mechanism exhibits many parallels with a nervous system. However, I am no authority on nervous systems, so my estimations on the similarity between Clique Space and a nervous system may be groundless, but I'd like that to be proven. My prototype is still incomplete, but I can now perhaps see what is left to be done.
Wednesday, October 3, 2012
An Intricate Mechanism.
Clique Space(TM) models collaborations as Cliques.
Cliques are made up of at least two Participants.
One Participant is the Clique's Owner.
Each of the Clique's Participants represents at least one device being used by an individual in the collaboration being modelled by the Clique.
The Clique has a medium which is determined by it's Owner and accepted by all other member Participants.
Each Participant has a mode which appropriately asserts how the member Participant's state conforms to that of the Owner.
The Clique's medium exposes the collaboration's characteristics to Clique Space.
A medium must be described by a flattened Media Profile hierarchy that contains a Media Profile root.
The root Media Profile describes the characteristics of the Clique Space components for a given Participant instance.
A Clique's medium is defined by a subset of the Owner's flattened Media Profile hierarchy.
All other member Participants must be able to describe the Clique's medium through flattening the Media Profile hierarchies of their constituent Connections.
A medium can be translated into a set of Enabling Constraint parameters.
A medium must be completely covered by the Participant's mode.
A mode is a set of Limiting Constraints which are primarily determined by a subset of the Owner's flattened Account Profile hierarchy.
The Clique's root Account Profile encodes the specific values that the Clique Space's data model take for a specific Participant.
Constituent Elements from a member's candidate may offer unspecified values or alternative value "compromises" to the set determined by flattening the nominated Account Profile hierarchies.
Limiting Constraints in an Account Profile flagged as not allowing compromises cannot be replaced by specific Limiting Constraints, whether from any other Element or unassigned.
All member Participants must be able to respond to changes in the Clique's mode which are made by the Owner to remain "in the Clique".
Member Participants leave their Clique.
Owner Participants disband their Clique.
A Clique will automatically disband should all member Participants leave.
The Owner can cede ownership to another member provided this other member accepts the title.
Member Participant candidates are made up of selected Connections and Affiliations, specific extra or compromise Limiting Constraints, and a selected Identity, all of which are used to determine the mode-form of a member Participant if created.
An Owner candidate specifies the same details as a member candidate, but also specifies a Clique's name.
Any Connection and Affiliation nominated in a candidate must have been "activated" against the same nominated Identity of the given candidate.
Any compromise or extra Limiting Constraint may only be specified from one of the nominated Affiliations or Connections, from the nominated Identity, from the Axle, or from one of the medium's Media Profiles.
Any number of extra Limiting Constraints unassigned to any given Element may be nominated in a candidate, and Limiting Constraints of this type are associated with the Participant they are expressed in should the Participant be created.
For any candidate, no more than one unassigned Limiting Constraint may cover an Enabling Constraint's parameter of the Clique's medium.
An unassigned Limiting Constraint must cover an Enabling Constraint's parameter of the Clique's medium.
A member candidate is asked to join an existing Clique, while an Owner candidate is asked to form a new Clique with one or more supplied member candidates.
A Clique Space knows of an indeterminate number of Element types, the first seven of which are:
Arrangements around a single Axle of instances from the remaining Elements represent a Client Device.
An instance of a node Media Profile or Connection can return a type which represents the type of device that can connect. Hence the reason why the number of Element types is indeterminate.
Limiting Constraints map to individual parameters of a Media Profile's Enabling Constraints.
One Enabling Constraint's parameter can only be covered by a single Limiting Constraint in any given Element.
A Participant's collection of Limiting Constraints express an individuals acceptance of the Clique's mode.
Zero or more Participants can be created from any Identity.
Every Participant must have an Identity, except where a Participant represents an unconnected device.
An Identity contains multiple Connections, any combination of which might be used in a Participant.
An Identity contains multiple Affiliations, any combination of which might be used in a Participant.
An Identity refers to a single Axle.
The expressed Connections and Affiliations within a single Identity instance are known as an Identity's constituents.
An Identity must contain no constituent with a Limiting Constraint that contradicts that of any other constituent.
A Connection associates an Axle with a node Media Profile.
A Connection contains the component that permits communication with the device in accordance with the associated Media Profile
A Media Profile contains the component that is used to decide whether a Participant using a medium which expresses the Media Profile has sufficient Limiting Constraint affinity to perform some action governed by the Media Profile.
An Affiliation associates an Axle with a node Account Profile.
The Axle associated in a Connection must be the Axle referred to in the Identities through which the Connection has been activated.
The Axle associated in an Affiliation must be the Axle referred to in the Identities through which the Affiliation has been activated.
The Axle represents the individual; a transcendent supervisory presence capable of possessing a device and using the device to participate in collaborations which are modelled as Cliques.
An individual, through a different, or even the same device or devices, may appear as one, two, or more Participants in the same Clique.
A device is something which can obtain a Connection to and exchange information with a Clique Space through an Agent Device.
An Agent Device is a type of device.
An administrator client is another type of device.
The administrator client renders Elements onto its View which have been projected from Agent Devices through which the administrator client has obtained Connections.
The administrator client provides a facility through which Agent Devices and Clique Spaces can be administrated.
The Agent Device is administered through its synaptic map.
A synaptic map is a type of Clique Space.
Agent Devices engage with other Agent Devices by creating synapses.
Agent Devices disengage with other Agent Devices by destroying synapses.
A synapse opens a channel through which transmitters are sent from one Agent Device to one other Agent Device.
A synapse on one Agent Device is a replication of another Agent Device's synaptic map.
A synapse is another type of Clique Space.
Agent Collaborations' Clique Spaces are Clique Spaces in which collaborative activity between external devices is recorded.
Agent Devices sharing direct membership of the Agent Collaboration are represented as Participants of the Agent Collaboration Clique Space's Clique.
There we go. A good summary. At the very least, a disclosure this detailed renders my technology prior art. I am not saying whether the summary I give is covered by my patent. I assert that this is the intent, but whether or not this is actually the case is not up to me.
Now, I appear still to have some (perhaps many) rather complicated unresolved issues. I am engineering a solution that will allow an Agent Device to transmit instructions to add and remove Elements' components to an administrator client. The administrator client must be capable of rendering "projected" Elements to its View of the Clique Space universe from the Agent Devices through which these transmissions are received. Agent Devices will also use the bulk of this mechanism to transmit components between themselves.
The thing about this whole Clique Space concept is that the data model described above is used to 1. model collaborations going on amongst Agent Devices and other external devices including the administrator client and to 2. determine which Agent Devices and which other external devices including the administrator client are recipients of changes in an Element's state. The Clique Space data model offers a simultaneous solution to the model and the controller pieces of the model-view-controller design pattern.
Point 2 of the above paragraph can be recast in this way: an Agent Device uses the data model to determine which other devices are interested in the state of Elements. This Agent Device will tell these other devices that the state of an Element has changed (an Element's component has been added or removed) if a particular device is registered as possessing an interest in this Element.
So, how is another device's interest in an Element registered in an Agent Device? Implementing the solution to this question is currently (and finally) occupying all my attention. The solution comes in two parts of its own.
In the first part, an administrator client (or any V/PM device) can receive information about the state of any Element from any Agent Device to which an external device is connected; potentially even from Clique Spaces other than the one or more Clique Spaces through which the external device's Connection's are obtained. The ability for the given external V/PM device to receive information about an Element is determined by the Limiting Constraints which are expressed in the serving Agent Device's Clique; a Clique created for any external device which also represents an instance of a Connection - an association between an Axle and a specific Media Profile type - through the given device to a Clique Space for which the Owner of the synaptic map's Clique (known by the engager Participant recorded as the Connection's originator component) transmits Element state.
The second part involves the transmission of element state information between Agent Devices through the Agent Device's Media Profile. The Agent Device's Media Profile exhibits the unique property in that the Participants in an Agent Collaboration's Clique are not transmissible between Agent Devices. An Agent Collaboration's Clique tells a particular Agent Device which other Agent Devices are interested in a particular Element. The fact that Participants in an Agent Collaboration's Clique are not transmissible avoids the possibility of infinite regress.
Participants generated from Connections which come from an Agent Device's Media Profile will appear in the serving Agent Device's Clique of the first part. The other Participant is generated from the external device's Connection. Both Participants of the serving Agent Device's Clique can be transmitted to other Agent Devices and to V/PM devices where constraints permit this transmission.
These questions make up the implementation of some very deep considerations I was entertaining when I conceived this concept. If I can actually implement the mechanisms I describe in the paragraphs above, I think I will have arrived at a proof of concept.
Cliques are made up of at least two Participants.
One Participant is the Clique's Owner.
Each of the Clique's Participants represents at least one device being used by an individual in the collaboration being modelled by the Clique.
The Clique has a medium which is determined by it's Owner and accepted by all other member Participants.
Each Participant has a mode which appropriately asserts how the member Participant's state conforms to that of the Owner.
The Clique's medium exposes the collaboration's characteristics to Clique Space.
A medium must be described by a flattened Media Profile hierarchy that contains a Media Profile root.
The root Media Profile describes the characteristics of the Clique Space components for a given Participant instance.
A Clique's medium is defined by a subset of the Owner's flattened Media Profile hierarchy.
All other member Participants must be able to describe the Clique's medium through flattening the Media Profile hierarchies of their constituent Connections.
A medium can be translated into a set of Enabling Constraint parameters.
A medium must be completely covered by the Participant's mode.
A mode is a set of Limiting Constraints which are primarily determined by a subset of the Owner's flattened Account Profile hierarchy.
The Clique's root Account Profile encodes the specific values that the Clique Space's data model take for a specific Participant.
Constituent Elements from a member's candidate may offer unspecified values or alternative value "compromises" to the set determined by flattening the nominated Account Profile hierarchies.
Limiting Constraints in an Account Profile flagged as not allowing compromises cannot be replaced by specific Limiting Constraints, whether from any other Element or unassigned.
All member Participants must be able to respond to changes in the Clique's mode which are made by the Owner to remain "in the Clique".
Member Participants leave their Clique.
Owner Participants disband their Clique.
A Clique will automatically disband should all member Participants leave.
The Owner can cede ownership to another member provided this other member accepts the title.
Member Participant candidates are made up of selected Connections and Affiliations, specific extra or compromise Limiting Constraints, and a selected Identity, all of which are used to determine the mode-form of a member Participant if created.
An Owner candidate specifies the same details as a member candidate, but also specifies a Clique's name.
Any Connection and Affiliation nominated in a candidate must have been "activated" against the same nominated Identity of the given candidate.
Any compromise or extra Limiting Constraint may only be specified from one of the nominated Affiliations or Connections, from the nominated Identity, from the Axle, or from one of the medium's Media Profiles.
Any number of extra Limiting Constraints unassigned to any given Element may be nominated in a candidate, and Limiting Constraints of this type are associated with the Participant they are expressed in should the Participant be created.
For any candidate, no more than one unassigned Limiting Constraint may cover an Enabling Constraint's parameter of the Clique's medium.
An unassigned Limiting Constraint must cover an Enabling Constraint's parameter of the Clique's medium.
A member candidate is asked to join an existing Clique, while an Owner candidate is asked to form a new Clique with one or more supplied member candidates.
A Clique Space knows of an indeterminate number of Element types, the first seven of which are:
- Axle
- Account Profile (node and root)
- Media Profile (node and root)
- Connection
- Affiliation
- Identity
- Participant
Arrangements around a single Axle of instances from the remaining Elements represent a Client Device.
An instance of a node Media Profile or Connection can return a type which represents the type of device that can connect. Hence the reason why the number of Element types is indeterminate.
Limiting Constraints map to individual parameters of a Media Profile's Enabling Constraints.
One Enabling Constraint's parameter can only be covered by a single Limiting Constraint in any given Element.
A Participant's collection of Limiting Constraints express an individuals acceptance of the Clique's mode.
Zero or more Participants can be created from any Identity.
Every Participant must have an Identity, except where a Participant represents an unconnected device.
An Identity contains multiple Connections, any combination of which might be used in a Participant.
An Identity contains multiple Affiliations, any combination of which might be used in a Participant.
An Identity refers to a single Axle.
The expressed Connections and Affiliations within a single Identity instance are known as an Identity's constituents.
An Identity must contain no constituent with a Limiting Constraint that contradicts that of any other constituent.
A Connection associates an Axle with a node Media Profile.
A Connection contains the component that permits communication with the device in accordance with the associated Media Profile
A Media Profile contains the component that is used to decide whether a Participant using a medium which expresses the Media Profile has sufficient Limiting Constraint affinity to perform some action governed by the Media Profile.
An Affiliation associates an Axle with a node Account Profile.
The Axle associated in a Connection must be the Axle referred to in the Identities through which the Connection has been activated.
The Axle associated in an Affiliation must be the Axle referred to in the Identities through which the Affiliation has been activated.
The Axle represents the individual; a transcendent supervisory presence capable of possessing a device and using the device to participate in collaborations which are modelled as Cliques.
An individual, through a different, or even the same device or devices, may appear as one, two, or more Participants in the same Clique.
A device is something which can obtain a Connection to and exchange information with a Clique Space through an Agent Device.
An Agent Device is a type of device.
An administrator client is another type of device.
The administrator client renders Elements onto its View which have been projected from Agent Devices through which the administrator client has obtained Connections.
The administrator client provides a facility through which Agent Devices and Clique Spaces can be administrated.
The Agent Device is administered through its synaptic map.
A synaptic map is a type of Clique Space.
Agent Devices engage with other Agent Devices by creating synapses.
Agent Devices disengage with other Agent Devices by destroying synapses.
A synapse opens a channel through which transmitters are sent from one Agent Device to one other Agent Device.
A synapse on one Agent Device is a replication of another Agent Device's synaptic map.
A synapse is another type of Clique Space.
Agent Collaborations' Clique Spaces are Clique Spaces in which collaborative activity between external devices is recorded.
Agent Devices sharing direct membership of the Agent Collaboration are represented as Participants of the Agent Collaboration Clique Space's Clique.
There we go. A good summary. At the very least, a disclosure this detailed renders my technology prior art. I am not saying whether the summary I give is covered by my patent. I assert that this is the intent, but whether or not this is actually the case is not up to me.
Now, I appear still to have some (perhaps many) rather complicated unresolved issues. I am engineering a solution that will allow an Agent Device to transmit instructions to add and remove Elements' components to an administrator client. The administrator client must be capable of rendering "projected" Elements to its View of the Clique Space universe from the Agent Devices through which these transmissions are received. Agent Devices will also use the bulk of this mechanism to transmit components between themselves.
The thing about this whole Clique Space concept is that the data model described above is used to 1. model collaborations going on amongst Agent Devices and other external devices including the administrator client and to 2. determine which Agent Devices and which other external devices including the administrator client are recipients of changes in an Element's state. The Clique Space data model offers a simultaneous solution to the model and the controller pieces of the model-view-controller design pattern.
Point 2 of the above paragraph can be recast in this way: an Agent Device uses the data model to determine which other devices are interested in the state of Elements. This Agent Device will tell these other devices that the state of an Element has changed (an Element's component has been added or removed) if a particular device is registered as possessing an interest in this Element.
So, how is another device's interest in an Element registered in an Agent Device? Implementing the solution to this question is currently (and finally) occupying all my attention. The solution comes in two parts of its own.
In the first part, an administrator client (or any V/PM device) can receive information about the state of any Element from any Agent Device to which an external device is connected; potentially even from Clique Spaces other than the one or more Clique Spaces through which the external device's Connection's are obtained. The ability for the given external V/PM device to receive information about an Element is determined by the Limiting Constraints which are expressed in the serving Agent Device's Clique; a Clique created for any external device which also represents an instance of a Connection - an association between an Axle and a specific Media Profile type - through the given device to a Clique Space for which the Owner of the synaptic map's Clique (known by the engager Participant recorded as the Connection's originator component) transmits Element state.
The second part involves the transmission of element state information between Agent Devices through the Agent Device's Media Profile. The Agent Device's Media Profile exhibits the unique property in that the Participants in an Agent Collaboration's Clique are not transmissible between Agent Devices. An Agent Collaboration's Clique tells a particular Agent Device which other Agent Devices are interested in a particular Element. The fact that Participants in an Agent Collaboration's Clique are not transmissible avoids the possibility of infinite regress.
Participants generated from Connections which come from an Agent Device's Media Profile will appear in the serving Agent Device's Clique of the first part. The other Participant is generated from the external device's Connection. Both Participants of the serving Agent Device's Clique can be transmitted to other Agent Devices and to V/PM devices where constraints permit this transmission.
These questions make up the implementation of some very deep considerations I was entertaining when I conceived this concept. If I can actually implement the mechanisms I describe in the paragraphs above, I think I will have arrived at a proof of concept.
Monday, September 10, 2012
Less on the Axle.
It is probably better that upon connecting, a Participant adapter (the Connection of an Agent Device or V/PM device) register itself with the Identity through which the Connection is expressed. This means that the Agent Device serving the device represented by the Participant adapter does not have to acquire the Axle's identifier in order to add a given Participant adapter to the Agent Device's set of served Participant adapters expressed in a given Axle. Perhaps this will permit the Agent Device instances to express these served Participant adapters in an Identity even when an Agent Device does not know the Identity's Axle.
It is hoped this will permit an individual to connect a device to an Agent Device operated by another individual without the first individual having to disclose their Axle to the second. I like this; it is a more flexible proposition.
It is hoped this will permit an individual to connect a device to an Agent Device operated by another individual without the first individual having to disclose their Axle to the second. I like this; it is a more flexible proposition.
Sunday, September 9, 2012
It is true. Your Axle is a private part that you may share with others, but if you give your sovereign away, your sovereignty goes with it.
How do I know who I am on Clique Space(TM)? How do I let others know who I am on Clique Space? How do others on Clique Space know who I am?
Axles serve an intimate purpose of self-identification. In Clique Space, Axles identify what is yours to yourself, and if you wish it, to others who you have nominated as being privy to your Axle's components, but especially the Axle's identifier. You can share or withhold this Element's identifier from disclosure through any Identity you have created. You know all these Identities are yours because they have been created only by you as the possessor of the Axle, and by using your Axle's sovereign - a private key which you never disclose to anyone else - to sign each Identity's identifier. You let others know each Identity you have created is yours by disclosing your Axle. If you don't want to let others know who is behind an Identity you publish, then you assign a Limiting Constraint to your Identity that prevents disclosure of your Axle to them.
I believe there is certainly a versatility - nay, even power - given to the individual in cyberspace through this Clique Space concept.
Now, to a more practical matter: the relaying of device activity to the individual Axle holder. This matter concerns, indeed, Clique Space mandates the concern of how devices having an interest in the Clique Space activity - any Agent Device or View/persistence mechanism-enabled (V/PM) device - are kept informed of the state of the one or more Clique Spaces to which the said devices are connected. In order for a device to be Clique Space aware, the device must be connected to a Clique Space. An individual - an Axle-holder - is really the thing capable of being aware of Clique Spaces just as they are aware of how hot or how hungry they may be; devices merely relay temperature or blood glucose levels to a device loosely called the brain wherein, in today's society, an individual appears manifest.
An Agent Device is a type of device which can talk to other Agent Devices. Agent Devices share information about Clique Space Elements, participating in the distribution of device activity throughout a Clique Space (a domain which is managed by a subset of the individuals who use the Clique Space) as the activity of all individuals who use the Clique Space. An individual, having both the capacity and the desire to observe or persist activity on a particular Clique Space connects one or more devices capable of doing this through their own Axle. In order to use these devices in any meaningful way, their Connections must be expressed through one or more Identities - created using the same Axle.
Any device which is not an Agent Device or a V/PM device is connected to a Clique Space using this same mechanism, but the Elements and components (really, just the components) used for and generated by the connection operation are not disclosed to the given device. This is because the device, not being an Agent Device or a V/PM device, doesn't have a facility to make sense of Clique Space Elements.
Lets now take a look at the Agent Device and the V/PM devices. These devices need a way of receiving information about the change in the state of all the connected devices. Now, any device (be it an Agent Device or a V/PM device) must be accessible from one collection within the Agent Device to which it is connected. It appears intuitive, and technically it is also a reasonable proposition, for the Axle's instance on a particular Agent Device to contain a set of all such Connection instances.
I have removed the notion of an "Adapter" interface except for the class called the Participant adapter - which is now implemented by any V/PM device. I think the adapter interface is a good candidate for massage so that the Agent Device's Connection can also implement this interface.
I predict some heavy-duty thinking over the next several weeks. For instance, if wer're going to use the adapter interface, then we must recognise that the methods on this interface must supply the same information for the Agent Device's Connection as is necessary for any other V/PM device.
This method's implementation on the Connection of the administrator client transmits a quantum from an Agent Device to a V/PM device. It has the following signature:
With both of these Connections implementing the same adapter, they can be contained within a set of adapters inside the same Axle as the one through which this Agent Device is connected. This, however, seems to hint at a complication: if each adapter of this set must name the same Axle in which this set is contained (must it?), then what happens if someone, using a different Axle, connects a V/PM device to this Agent Device? Is it possible that this ominous restriction is actually a ray of clarification?
The Agent Collaboration's Connection would surely implement the transmit method differently to the V/PM device; rather than transmitting the transmitter directly to the device (this would be the case in any instance of a V/PM device that I can currently think of), the Agent Collaboration's Connection would find its associated Participant (of which there would only be one) and transmit the information to all other members of the Clique excluding itself. This mechanism is detail around the concept exactly as I envisaged in mid-2004.
Some heavy-duty thinking to flesh out and implement this mechanism is needed indeed, but more than eight years of heavy-duty thinking has drawn me slowly to the acceptance that this overall concept will eventually be proven.
We'll see...
Axles serve an intimate purpose of self-identification. In Clique Space, Axles identify what is yours to yourself, and if you wish it, to others who you have nominated as being privy to your Axle's components, but especially the Axle's identifier. You can share or withhold this Element's identifier from disclosure through any Identity you have created. You know all these Identities are yours because they have been created only by you as the possessor of the Axle, and by using your Axle's sovereign - a private key which you never disclose to anyone else - to sign each Identity's identifier. You let others know each Identity you have created is yours by disclosing your Axle. If you don't want to let others know who is behind an Identity you publish, then you assign a Limiting Constraint to your Identity that prevents disclosure of your Axle to them.
I believe there is certainly a versatility - nay, even power - given to the individual in cyberspace through this Clique Space concept.
Now, to a more practical matter: the relaying of device activity to the individual Axle holder. This matter concerns, indeed, Clique Space mandates the concern of how devices having an interest in the Clique Space activity - any Agent Device or View/persistence mechanism-enabled (V/PM) device - are kept informed of the state of the one or more Clique Spaces to which the said devices are connected. In order for a device to be Clique Space aware, the device must be connected to a Clique Space. An individual - an Axle-holder - is really the thing capable of being aware of Clique Spaces just as they are aware of how hot or how hungry they may be; devices merely relay temperature or blood glucose levels to a device loosely called the brain wherein, in today's society, an individual appears manifest.
An Agent Device is a type of device which can talk to other Agent Devices. Agent Devices share information about Clique Space Elements, participating in the distribution of device activity throughout a Clique Space (a domain which is managed by a subset of the individuals who use the Clique Space) as the activity of all individuals who use the Clique Space. An individual, having both the capacity and the desire to observe or persist activity on a particular Clique Space connects one or more devices capable of doing this through their own Axle. In order to use these devices in any meaningful way, their Connections must be expressed through one or more Identities - created using the same Axle.
Any device which is not an Agent Device or a V/PM device is connected to a Clique Space using this same mechanism, but the Elements and components (really, just the components) used for and generated by the connection operation are not disclosed to the given device. This is because the device, not being an Agent Device or a V/PM device, doesn't have a facility to make sense of Clique Space Elements.
Lets now take a look at the Agent Device and the V/PM devices. These devices need a way of receiving information about the change in the state of all the connected devices. Now, any device (be it an Agent Device or a V/PM device) must be accessible from one collection within the Agent Device to which it is connected. It appears intuitive, and technically it is also a reasonable proposition, for the Axle's instance on a particular Agent Device to contain a set of all such Connection instances.
I have removed the notion of an "Adapter" interface except for the class called the Participant adapter - which is now implemented by any V/PM device. I think the adapter interface is a good candidate for massage so that the Agent Device's Connection can also implement this interface.
I predict some heavy-duty thinking over the next several weeks. For instance, if wer're going to use the adapter interface, then we must recognise that the methods on this interface must supply the same information for the Agent Device's Connection as is necessary for any other V/PM device.
This method's implementation on the Connection of the administrator client transmits a quantum from an Agent Device to a V/PM device. It has the following signature:
- void transmit(SourceParticipantAdapter
participantAdapter,Transmitter transmitter)
throws CliqueSpaceException;
With both of these Connections implementing the same adapter, they can be contained within a set of adapters inside the same Axle as the one through which this Agent Device is connected. This, however, seems to hint at a complication: if each adapter of this set must name the same Axle in which this set is contained (must it?), then what happens if someone, using a different Axle, connects a V/PM device to this Agent Device? Is it possible that this ominous restriction is actually a ray of clarification?
The Agent Collaboration's Connection would surely implement the transmit method differently to the V/PM device; rather than transmitting the transmitter directly to the device (this would be the case in any instance of a V/PM device that I can currently think of), the Agent Collaboration's Connection would find its associated Participant (of which there would only be one) and transmit the information to all other members of the Clique excluding itself. This mechanism is detail around the concept exactly as I envisaged in mid-2004.
Some heavy-duty thinking to flesh out and implement this mechanism is needed indeed, but more than eight years of heavy-duty thinking has drawn me slowly to the acceptance that this overall concept will eventually be proven.
We'll see...
Monday, September 3, 2012
How is information distributed through Clique Space(TM)?
This question is a bit obvious, but it is one which I had no specific answer for when I put my patent together.
When I conceived the Clique Space(TM) data model, I took as an article of some speculative faith, the premise that I could work out the technical considerations of how this model would be used to realise the mechanism that actually allows one Agent Device to exchange information with one or more others, as well as how one Agent Device exchanges Clique Space Element information for external device state information. I had hypothesised that mechanisms would emerge as a result of the deliberations necessary to get from the concept recorded in the patent, to its implementation recorded in code.
I envisaged that perhaps some degree of similarity between Clique Spaces and biological nervous systems would emerge, and indeed, this appears to have happened in at least one example: the emergence of the logical synapse necessary to open a channel for exchange between two Agent Devices. Although the synapse is reasonably stable, my current deliberations will have an impact on this mechanism because the changing form of the information exchange will also change the way Agent Devices engage and disengage, forming and disbanding bipartite Cliques which represent these synapses. Although I had thought the synapse might emerge as far back as when I put the patent together, this hypothetical mechanism lacked the implementation detail that exists currently; it is anticipated that some of this current detail will have been discarded and replaced before one can confidently say the synapse mechanism exhibits its final form.
The wider deliberation of the mechanism needed to get collections of Agent Devices, being members of a Clique, to communicate the changing state of their Elements amongst each other have brought me to yet other limits of my intellectual capacity as it was when I put the patent together. I feel that the implementation has evolved to a point where, since stabilising the implementation of the properties mechanism discussed in my last post - an act in itself which has pointed me the way to the promise of an answer - I now appear prepared to start replacing at least some of this faith with some reason.
At least at a purely logical level, I think my progression from this point may provide some interesting insight into how a biological nervous system recruits and coordinates its individual neurons in the performance of some act instigated by and for the organism as a whole. Such a mechanism would exhibit hierarchical and executive command and control structures, but would also simultaneously appear to self-assemble based on some form of consensus between neurons (Agent Devices) in accordance with the varying capacity of each neuron to participate. Hence, it would be very hard in any Clique Space (indeed, as it might be demonstrated in any neural system) to point to a single Agent Device as being ultimately responsible for the conduct of any Clique Space as a whole.
Whether synthetic or biological, any such system would definitely require some systematic form of message propagation. It is to this mechanism that my deliberations appear once more to turn. I have some general ideas which I hope to test. For instance, as I explained in a previous post, I see the necessity for Agent Devices to have two Cliques model a single collaboration between a collection of devices, whether these devices are Agent Devices being members of a Clique space, or a collection of devices participating in a collaboration defined by a Media Profile type external to the Clique Space implementation.
The first Clique primarily models what is actually going on in the collaboration; it gives Clique Space a sense of the collaboration's reason for existence, and to the characteristics of its member Participants in accordance to the ability of the Clique's medium to report the collaboration's activity. The second Clique is used to model which Agent Devices have a stake in knowing what is going on in the first Clique by virtue of the fact that any member Participants of this Agent Collaboration's Clique share a combination of the following three relationships with the first Clique: 1. that these Agent Devices are connected to the devices who's collaborative activity is being modelled as participants of the first Clique, or 2. that these Agent Devices are connected to a View or persistence mechanism-enabled devices viewing or persisting activity of the first Clique, and optionally, may be capable of controlling the first Clique, or 3. that these Agent Devices may be acting as relay devices, permitting propagation of Element state from Agent Devices of the first two types located in one physical location to those located in another, but for which the Agent Devices at the first location share no synapses with those at the second; perhaps a bit like a corpus callosum.
This dual-Clique scheme seems a reasonable way to propagate messages amongst relevant Agent Devices, but this mechanism does not include View or persistence devices, because they are not Agent Devices, and hence lack the mechanics necessary to participate in an Agent Collaboration. These type of external devices require another protocol to receive and process Element state information, even if these devices use the same message transport vehicle - the component transmitter, discussed in the previous entry - used in the Agent Collaboration.
It might be interesting at this point to consider how it is a designed intent that the Media Profile Element fits the bill for encoding the protocol for any collaboration type so an Agent Device can receive, process, and control device state. The information content generated by any device may be augmented with Clique Space information in the given device's media in accordance with the Media Profile through which a Connection has been established. The general concept of the Media Profile is used to describe the parameters that a specific protocol will accept. Specifically, the protocols which describe the operational parameters of 1. the Agent Collaboration, and 2. the administrator client, are exposed through Media Profiles like any other protocols. Hence, the Agent Collaboration's protocol is exposed inside the mechanism that implements this protocol by an Agent Collaboration Media Profile so the Agent Collaboration's activity, modelled as a Clique, can be Viewed, persisted, or controlled by an administrator client or any external device which possesses such a capability.
Hence, the Agent Devices have their Agent Collaboration Media Profile. This Media Profile provides the mechanism that realises the second Clique necessary for the dual-Clique propagation scheme. A Media Profile for the administrator client will be fashioned that facilitates the component exchange scheme between an Agent Device and a View or persistence enabled external device. Both the administrator client's component exchange and the Agent Device's dual-Clique schemes will use the common component propagation and exchange mechanism - the component transmitter.
The component transmitter mechanism currently looks like the ideal candidate for the administrator client component exchange scheme as it is for the Agent Device's dual-clique scheme. This is the intention for the design of the component transmitter mechanism; this mechanism replaces the failed Element precis mechanism for the Agent Collaboration, and a promising, but demonstrably inadequate Element projection mechanism for the administrator client. Both the failure of the Element precis and the inadequacy of the Element projection mechanisms prompted me to look to the component transmitter mechanism as a sufficient and flexible alternative candidate for a solution to the question of message propagation.
When I conceived the Clique Space(TM) data model, I took as an article of some speculative faith, the premise that I could work out the technical considerations of how this model would be used to realise the mechanism that actually allows one Agent Device to exchange information with one or more others, as well as how one Agent Device exchanges Clique Space Element information for external device state information. I had hypothesised that mechanisms would emerge as a result of the deliberations necessary to get from the concept recorded in the patent, to its implementation recorded in code.
I envisaged that perhaps some degree of similarity between Clique Spaces and biological nervous systems would emerge, and indeed, this appears to have happened in at least one example: the emergence of the logical synapse necessary to open a channel for exchange between two Agent Devices. Although the synapse is reasonably stable, my current deliberations will have an impact on this mechanism because the changing form of the information exchange will also change the way Agent Devices engage and disengage, forming and disbanding bipartite Cliques which represent these synapses. Although I had thought the synapse might emerge as far back as when I put the patent together, this hypothetical mechanism lacked the implementation detail that exists currently; it is anticipated that some of this current detail will have been discarded and replaced before one can confidently say the synapse mechanism exhibits its final form.
The wider deliberation of the mechanism needed to get collections of Agent Devices, being members of a Clique, to communicate the changing state of their Elements amongst each other have brought me to yet other limits of my intellectual capacity as it was when I put the patent together. I feel that the implementation has evolved to a point where, since stabilising the implementation of the properties mechanism discussed in my last post - an act in itself which has pointed me the way to the promise of an answer - I now appear prepared to start replacing at least some of this faith with some reason.
At least at a purely logical level, I think my progression from this point may provide some interesting insight into how a biological nervous system recruits and coordinates its individual neurons in the performance of some act instigated by and for the organism as a whole. Such a mechanism would exhibit hierarchical and executive command and control structures, but would also simultaneously appear to self-assemble based on some form of consensus between neurons (Agent Devices) in accordance with the varying capacity of each neuron to participate. Hence, it would be very hard in any Clique Space (indeed, as it might be demonstrated in any neural system) to point to a single Agent Device as being ultimately responsible for the conduct of any Clique Space as a whole.
Whether synthetic or biological, any such system would definitely require some systematic form of message propagation. It is to this mechanism that my deliberations appear once more to turn. I have some general ideas which I hope to test. For instance, as I explained in a previous post, I see the necessity for Agent Devices to have two Cliques model a single collaboration between a collection of devices, whether these devices are Agent Devices being members of a Clique space, or a collection of devices participating in a collaboration defined by a Media Profile type external to the Clique Space implementation.
The first Clique primarily models what is actually going on in the collaboration; it gives Clique Space a sense of the collaboration's reason for existence, and to the characteristics of its member Participants in accordance to the ability of the Clique's medium to report the collaboration's activity. The second Clique is used to model which Agent Devices have a stake in knowing what is going on in the first Clique by virtue of the fact that any member Participants of this Agent Collaboration's Clique share a combination of the following three relationships with the first Clique: 1. that these Agent Devices are connected to the devices who's collaborative activity is being modelled as participants of the first Clique, or 2. that these Agent Devices are connected to a View or persistence mechanism-enabled devices viewing or persisting activity of the first Clique, and optionally, may be capable of controlling the first Clique, or 3. that these Agent Devices may be acting as relay devices, permitting propagation of Element state from Agent Devices of the first two types located in one physical location to those located in another, but for which the Agent Devices at the first location share no synapses with those at the second; perhaps a bit like a corpus callosum.
This dual-Clique scheme seems a reasonable way to propagate messages amongst relevant Agent Devices, but this mechanism does not include View or persistence devices, because they are not Agent Devices, and hence lack the mechanics necessary to participate in an Agent Collaboration. These type of external devices require another protocol to receive and process Element state information, even if these devices use the same message transport vehicle - the component transmitter, discussed in the previous entry - used in the Agent Collaboration.
It might be interesting at this point to consider how it is a designed intent that the Media Profile Element fits the bill for encoding the protocol for any collaboration type so an Agent Device can receive, process, and control device state. The information content generated by any device may be augmented with Clique Space information in the given device's media in accordance with the Media Profile through which a Connection has been established. The general concept of the Media Profile is used to describe the parameters that a specific protocol will accept. Specifically, the protocols which describe the operational parameters of 1. the Agent Collaboration, and 2. the administrator client, are exposed through Media Profiles like any other protocols. Hence, the Agent Collaboration's protocol is exposed inside the mechanism that implements this protocol by an Agent Collaboration Media Profile so the Agent Collaboration's activity, modelled as a Clique, can be Viewed, persisted, or controlled by an administrator client or any external device which possesses such a capability.
Hence, the Agent Devices have their Agent Collaboration Media Profile. This Media Profile provides the mechanism that realises the second Clique necessary for the dual-Clique propagation scheme. A Media Profile for the administrator client will be fashioned that facilitates the component exchange scheme between an Agent Device and a View or persistence enabled external device. Both the administrator client's component exchange and the Agent Device's dual-Clique schemes will use the common component propagation and exchange mechanism - the component transmitter.
The component transmitter mechanism currently looks like the ideal candidate for the administrator client component exchange scheme as it is for the Agent Device's dual-clique scheme. This is the intention for the design of the component transmitter mechanism; this mechanism replaces the failed Element precis mechanism for the Agent Collaboration, and a promising, but demonstrably inadequate Element projection mechanism for the administrator client. Both the failure of the Element precis and the inadequacy of the Element projection mechanisms prompted me to look to the component transmitter mechanism as a sufficient and flexible alternative candidate for a solution to the question of message propagation.
Monday, August 27, 2012
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.
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.
Subscribe to:
Posts (Atom)