Wednesday, July 3, 2013

A small epiphany today: the candidate as a key.

I've just resumed my 6k jogs after nearly two weeks of less than great weather. Just before I went on today's stint, I had a small epiphany that has since spread its tendrils of enlightenment over the whole concept, revealing perhaps many answers to problems that hitherto remained without an answer.

The epiphany happened like this: I was getting ready to go out for my jog, and I was just trying to capture my thoughts as comments in the AdministratorClientMediaProfile class. I'm working on the connect method of this class; a remote method call from an administrator client when someone attempts to connect one to an Agent Device member of their Sovereign's Clique Space.

It was intended that the candidate data structure be used to communicate two things: a collection of named enabling constraints and a collection of properties. These candidates would come in two subtypes: the Owner's candidate would indicate such properties as would be expressed in an Owner Participant, and the member's candidate would indicate such properties as would be expressed in a member Participant. The current placement of this candidate as a structure which can be used in a remote call has fallen out of favour. The candidate as it is currently implemented appears inappropriate.

I made some wistful half-formed remarks about declaring candidate "templates" as a property of an Identity and left for my jog. As I walked out my door, a small frisson buzzed me. I thought to myself that it would just be better to think of the candidate as a named object which contains Enabling Constraints and the location, within the Identities scope, of properties which would fit into parameters of these Enabling Constraints to yield a Participant's Limiting Constraints.

While I was jogging, I did some more thinking. When I got back, I re-edited my comments and what I put down earlier evolved into what has been re-quoted here:
  • Consider moving the concept of the candidate into more of a central role as an internal property of an Identity. This may be a good way to establish connection semantics for all external devices. A candidate might then need only be referred to by its name when a connection is requested through an external device.
The candidate has taken a new, and hopefully a simpler position within the implementation. The candidate is a key that is used to instruct an external device to connect to a Clique Space. Entries in the Identity's internal candidates property can be referred to by name when a device is being used to request its connection to a Clique Space. Hence, to reference a candidate held in an Identity, all that needs to be communicated from the device is a candidate's name. Usage of a named candidate in this way appears to be precisely how a user would prefer to determine the way an external device might initiate a connection with the user's sovereign Clique Space so the device can then be engaged with other devices through Clique Space.

Structurally, the candidate completely specifies the set of Media Profiles that determine the Participant's medium. The candidate key, on the other hand, only draws specific mode entries form the Mode Profile spine, so that when the Participant is being formed, additional Properties can be taken from wherever they reside in the Connections and the Connections' Media Profiles.

At the moment, I still think that there will be times where a named candidate will not provide a flexible option when engaging a device once it is connected to a Clique Space. There will be plenty of times where it still appears necessary to be able to create a candidate for a single use; especially in a situation where an individual needs to be flexible, and admit a form of compromise so the Clique can form and some process governed by this Clique can ensue.

Currently, I still think it good to turn this paradigm shift over in my head for a little while yet to see if I can work out if any anomaly renders it unsuitable before I move to implement.

No comments:

Post a Comment