Determination of the Clique's medium.

Right now, I feel that I can direct my attention toward some very central issues of the Clique Space(TM) purpose.

The light of my enquiry appears to shine almost squarely on the issue of determining the medium which every Participant in a specific Clique will have. This blog entry therefore is some deliberation over the considerations central to this mechanism, and some implications on other mechanisms incident by this mechanism.

Every candidate Participant supplies a collection of Connections which represent devices underlying a given Participant if it were created. Each candidate supplies a set of one or more Connections which have been activated against an Identity, also given in the candidate. The Clique's medium is determined primarily by the candidate which is nominated as the Owner Participant.

The Owner's medium is determined by iterating through the Owner candidate's given set of Connections. For each Connection, the associated Media Profile hierarchy is flattened, and returned as a set of Media Profiles. Each of these iterations progressively builds a baseline medium; each iteration is the logical union between the Media Profile name correspondence from the Connection of the given iteration with the set which has been built in previous iterations. One of the Owner candidate's Connections is nominated as the Participant's Connection: it is the Connection on the device spine which will yield the type of Participant desired; the Media Profile, the Connection, and the hypothetical Participant are collectively known as the device's spine. Each of these elements extends the respective abstract Clique Space's element class declaration.

The other member candidates describe other sets of Connections from the same or other identities through which a similar process of building a set of Media Profiles will happen. Each member contributes to determining the Clique's medium: at the end of determining the medium for each member, the Owner's medium is trimmed by finding the logical intersection between the Owner's medium and each member. This is done progressively until all members have been iterated through.

The final medium obtained in this process is the maximum degree of functionality common to all candidates which can be contained by the candidate Owner Participant. The final consideration regarding the medium is to determine whether the given medium will be accepted by the spinal Connection. The Clique cannot form if any Media Profile present in the candidate medium is not present in the spinal medium. The spinal medium is found by flattening the hierarchy of the given spine's Media Profile as it is for any of the candidates' media.

Each member Participant is assigned its own version of the Owner's medium. This is because medium equivalence is determined by the correspondence between the name of the Owner's and member's Media Profile name. Hence, the name of the Media Profile is sufficient to determine equivalence and this means that a member can specify a name-equivalent Media Profile from a different Clique Space. The use of name-equivalent, but different Media Profile instances for different candidates may become a consideration in determining the Clique's mode when determining whether a Clique can form.

In some ways, the Clique's mode is very similar to its medium, but considerations regarding the Clique's mode depend on consensus between all the Clique's members; not primarily on the Owner's functional capacity.

Calculating the mode is determined by marrying all the Limiting Constraints specified by a given candidate to the Enabling Constraints of the derived medium, and also evaluating whether all candidates share Limiting Constraint affinity; the Clique cannot form if one or more members have properties which contradict the intentions of others.

A more algorithmic explanation around determining the Clique's mode will be covered in a later blog entry. :)

Something is sitting in my head.

I've got something in my head. I've been working on it in there since last Monday, and it'll have to remain in there until I file and serve my submissions in an application IBM's legal counsel have made in my case to have it struck out. Too bad there perhaps. Perhaps not. Perhaps I'll know on 19 April.

Back to my head and to the things therein.

I'm looking at what I perceive to be a solution that revisits deliberations around the same subject matter given in this entry in such a way that draws on the inherent abstract nature of the core data model. What is in my head is promising a lot.

In order to understand what is in my head, one needs to understand how every piece of information an Agent Device knows of (everything except Cliques) must be expressible as a component (well, more correctly, a transmissible component) before it can be propagated to other Agent Devices or projected to other V/PM-enabled devices. All components except the Sovereign's Clique Space are transmissible, and all transmissible components except the "observer" Participant are observable. Identifiers are not components, but do have a method named asQuantum that accepts no parameters.

The asQuantum method is also declared in the transmissible component interface so these type of components can be represented as a serialisable quantum which can be propagated or projected or persisted. All Elements implement the transmissible component interface, and delegate to the enclosed identifier's asQuantum method in the corresponding Element's asQuantum method.

The lovely observation my head has captured about the third category of component (the observable transmissible component) described above is that components of this type are indeed "observable". That is, these type of components have an observer - an "observer" Clique composed entirely of "observer" Participants. This Clique registers all devices (whether Agent Devices or any V/PM device - collectively  known as "observer" devices) that are interested in a particular "observable transmissible" component.

I can't wait to start work on this. I reckon this mechanism is the final key to a demonstrable prototype. The thing about this mechanism is that it (or the something that truly has to be implemented) has been in my head since mid-2004. It is only now, however, that the implementation of everything else had to be done before I was sufficiently prepared to investigate this observer mechanism.

Maybe I'm just a dickhead. Eureka!