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.
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.