Deliberating Constraints...

As the Clique Space(TM) implementation evolves and matures, I feel the growing necessity of entertaining the notions of Enabling and Limiting Constraints. Although these pieces of my concept exist in the implementation, a realisation approaching the intended purpose is still wanting.

So, my patent spec describes two main types of constraints: the Enabling Constraint - one of these describe some functional parameter of some type of "real" device; and the Limiting Constraint - a value that an Enabling Constraint can take. Enabling Constraints are contained inside Media Profiles because Media Profiles describe functionality of a specific real device type, or, in the case where a Media Profile hierarchy is used to describe a real device, an individual Media Profile node in this hierarchy can be used to describe some set of functionality that can be used to distinguish, categorise, and collectively, to build, different real device variants. Limiting Constraints are contained inside any Element, including Media Profiles, and are set by device vendors to shape the device's function according to some physical limitations, by users in accordance with personal identity preferences, by organisations in order that device behaviour be reflective of organisational goals, or Clique Space administrators so to maintain a Clique Space's stable functioning.

Although any Element can contain zero or more Limiting Constraints, it only appears necessary and consistent to model and control device state through Limiting Constraints inside the Participant Element because the Participant represents a real device as it is participating in a real collaboration going on in a real medium in the real world; whatever all that - determined by possibly one or more, but at least one Media Profile hierarchy - might actually mean.

Now that I've set this stage, I can talk about the contents of my current deliberations...

From the blather above, one can surmise that an Element is a collection of Limiting Constraints which express values that certain device properties can take, and that a particular type of Element - the Media Profile - contains Enabling Constraints which expose those properties to a Clique Space. Additionally, for this deliberation, it is also necessary to consider that all of these Elements have specific relationships to each other. For example, a Connection is an association of one or more Media Profiles with exactly one Account.

Clique Space is realised through the Agent Device. An Agent Device is a device, and like any device, the Agent Device can be modelled in a Clique Space. Because Clique Space expresses the properties of a device as a set of Enabling Constraints, relationships between Elements - as in the above example, a Connection's Media Profiles and Account are components of the given Connection - can be expressed as Enabling Constraints.

Up to now, economy has mandated I declare specific instance variables for these defined relationships. However, because these relationships can be expressed as Enabling Constraints, the time has come, perhaps, for me to really go to work on progressing the implementation of these Enabling and Limiting Constraints. Time might be ripening for me to work out a protocol for determining when to check for constraint affinity as well as the subject of the necessity of a call-back mechanism that could be used to programmatically compare constraints according to what is necessary for particular devices.

This deliberation kind of fits in with my want to test the administrator Client and Agent Device's implementations of the undisclosed Element and identifier: part of the deliberation point of my previous post. Having now just implemented these, I cannot actually see them in use because the Agent Devices don't currently create or transmit undisclosed Elements or identifiers to other Agent Devices, nor do Agent Devices project undisclosed Elements or identifiers to administrator Client Devices. All this is because there currently exists no mechanism to determine that a receiving Agent or administrator Client Device has insufficient constraint affinity: part of the deliberation point of this post.

We'll see where I'll go from here... I'm pulling the draw strings tighter on this proof-of-concept; in some sense, I'm watching disparate pieces finally come together.