What use the Active Affiliation?

I've been pondering whether the Active Affiliation serves any specific purpose for some time, having talked briefly about this subject before.

The Active Affiliation Element was intended as a kind of state-object that connected devices would acquire to indicate that the connection was authenticated. Devices that possess a View would then use their Active Affiliation to form a Clique with their serving Agent Device. Other devices that did not receive View information from the serving Agent Device would acquire Participants when engaged with relevant other devices in Clique Space, otherwise devices would possess a lone Active Affiliation when not engaged with other devices in any collaboration.

Now that I'm developing the concept, my understanding of the relevance of each of the pieces shifts and one consequence of this appears to be that I'm being drawn to the conclusion that the Active Affiliation is redundant, and the Participant can take on the intended 'authentication' purpose of the Active Affiliation implying that media spines might only have three vertebrae: the Media Profile, Connection, and Participant Elements. The serving Agent Device's Participant and the bipartite Clique in which both Participants exist, is generated for all devices -- the mode of which differs with the type of device and what state information it exchanges with the serving Agent Device through which the device is connected to the Clique Space in question.

All this leads more directly to the convenience, or rather, the very point of Clique Space: Cliques model collaborations. And because every device has to "collaborate" with a serving Agent Device, at a minimum every device must form a Clique with its serving Agent Device before any View or log-based device can observe this collaboration and discover other collaborations this device might be involved in which are being modelled (and possibly controlled) by the Clique Spaces over which their Cliques span.

Now, my proof-of-concept has been evolving for some time. While the removal of the Active Affiliation from the core data model will ultimately simplify the implementation, this procedure is to going to be messy. Obviously, I'm going to consider this issue for some time yet while other issues are worked through.

Clique Space(TM) administrator Client Device command grammar.

After committing my last revision (I think it was 478) which has seen a stable implementation of the Agent Device disengage process, I decided it would be a good idea to map the assortment of commands available to the Client Device in a reasonably formal grammar.

The notation I have ascribed to is my own, developed as I put the grammar together; it should be fairly easy to work out, and although the elements "schema:label" form may lend itself to a meta-notation, I have not given such a schema the little consideration required beyond this because I don't currently care to.

Here it is:

command:=

command-clause:without-delegate|

{keyword:with value:delegate-identifier command-clause:with-delegate}

command-clause:without-delegate:=

command-clause:disband|

{keyword:list command-clause:list-without-delegate}|

command-clause:connect|

command-clause:show-or-hide-Clique-Space|

keyword:help|keyword:exit

command-clause:list-without-delegate:=

command-clause:list-Clique-Space|

command-clause:list-structure|

command-clause:list-Clique-without-delegate|

command-clause:list-Element-without-delegate|

keyword:rmi|

keyword:tokens|

keyword:cliques|

keyword:cliquespaces|

keyword:elements

command-clause:list-Clique-Space:=

keyword:cliquespace value:Clique-Space

command-clause:list-structure:=

keyword:structure keyword-clause:Element-type value:Element-identifier

command-clause:list-Clique-without-delegate:=

keyword:clique [value:Clique]

command-clause:list-Element-without-delegate:=

keyword:element keyword-clause:Element-type value:Element-identifier

command-clause:connect:=

keyword:connect value: Agent-Device-name

[keyword:accountprofile value:Account-Profile-name]

[keyword:cliquespace value:Clique-Space-name]

command-clause:show-or-hide-Clique-Space:=

keyword:show|keyword:hide value:Clique-Space-name

command-clause:with-delegate:=

command-clause:Particpant-adapter|

command-clause:Active-Affiliation-adapter|

command-clause:Connection-adapter

command-clause:Participant-adapter:=

command-clause:list-with-delegate|

command-clause:disband|

command-clause:join|

command-clause:leave|

command-clause:deactivate-other|

command-clause:form-other|

command-clause:activate-other|

command-clause:disconnect-other|

command-clause:create|

command-clause:destroy|

command-clause:Active-Affiliation-adapter

command-clause:Active-Affiliation-adapter:=

keyword:deactivate|

command-clause:form-self|

command-clause:Connection-adapter

command-clause:Connection-adapter:=

keyword:disconnect|

{keyword:activate command-clause:activate-self}

command-clause:list-with-delegate:=

keyword:list command-clause:list-Clique-with-delegate|command-clause:list-Element-with-delegate

command-clause:list-Clique-with-delegate:=

keyword:clique delegate-token:Participant-adapter value:Clique-name

command-clause:list-Element-with-delegate:=

keyword:element delegate-token:Connection-adapter keyword-clause:Element-type value:Element-identifier

command-clause:disband:=

keyword:disband [value:Clique-name]

command-clause:join:=

keyword:join value:Clique value:Clique-Space value:Active-Affiliation-identifier*

command-clause:leave:=

keyword:leave value:Participant-identifier*

command-clause:deactivate-other:=

keyword:deactivate value:Active-Affiliation-identifier

command-clause:form-other:=

keyword:form value:Clique-name value:Clique-Space-name value:owner-Active-Affiliation-identifier

value:member-Active-Affiliation-identifier*

command-clause:activate-other:=

command-clause:activate-self value:Connection-identifier

command-clause:disonnect-other:=

keyword:disconnect value:Connection-identifier

command-clause:form-self:=

keyword:form [keyword:clique value:Clique-name] [keyword:cliquespace value:Clique-Space-name]

value:Active-Affiliation-identifier*

command-clause:activate-self:=

value:Active-Affiliation-identifier

command-clause:create:=

keyword:create

{keyword:account value:user-identifier}|

{keyword:accountprofile keyword:name [value:Account-Profile-identifier*]}|

{keyword:affiliation value:Account-identifier value:Account-Profile-identifier}

command-clause:destroy:=

keyword:destroy keyword-clause:non-spinal-Element-type value:Element-identifier

keyword-clause:Element-type:=

keyword-clause:non-spinal-Element-type|

keyword:mediaprofile|

keyword:connection|

keyword:activeaffiliation|

keyword:participant

keyword-clause:non-spinal-Element-type:=

keyword:account|

keyword:accountprofile|

keyword:affiliation

I believe this grammar discloses a lot about my concept. Although perhaps disclosure of this detail is fraught with intellectual property hazard, I hope it might stand as proof to some that what I am doing is of realisable value, and that some day, a society might actually pay me recognition for this value. These are the motivations for publishing.

Clique Space(TM): A disengaging development.

Earlier this afternoon, and although perhaps a bit rough, I can now get two Agent Devices to disengage. The engage/disengage process has a wonderful parallel to the notion of the Agent Collaboration. This is because, like the Agent Collaboration (a manifestation of a Clique Space), a relationship being formed in the engage process and destroyed in the disengage process between two Agent Devices can be modelled as a Clique. As I have said before, this product, representing precisely two conjoined Agent Devices, appears to me to necessarily mirror the function of a synapse.

Because Clique Space should be able to model any collaboration between (or even within) a device, Clique Space should be capable of modelling collaborations between its own components. Hence, this means modelling collaborations at two levels: 1; at the level of the engage/disengage Agent Device Clique Space's synapse, and 2; at the level of form/join/leave/disband Agent Collaboration Clique Space's Clique.

Now, it appears that I still have one substantial obstacle to realising a minimally functional prototype: the Agent Collaboration's pulse message. At this time, functional specifics of a pulse are very sketchy, and much more thought than has been the case up until now will be directed to this pulse thing. While I deliberate, I will revisit the Client Device with the hope of simplifying its command syntax. This will hopefully 1; make a demonstration easier to understand, and 2; allow me to add commands in a more orderly manner, which will hopefully simplify the introduction of commands concerning the pulse message.

The Client and Agent Devices are co-evolving components; a significant observable property of Clique Space's development process is how development alternates, and at times goes on simultaneously, between the Agent and Client Devices.

Clique Space(TM) Progress Report.

Most of my time has been taken up by coding my proof-of-concept, and hence, I haven't been generating as many of these web log entries this year. That's no bad thing because I can't keep talking without an implementation. This implementation continues to evolve, although very slowly; such is the pace set by the capricious, somewhat bone lazy, wandering endeavour of one individual.

Anyway, a sufficient interface between the Agent and the Client Device appears to have been implemented, and so, most time of the near to medium term will now concentrate on what goes on between Agent Device instances: the Agent Device's and Collaboration's Clique Space. There is still much work to be done here.

Nose to the grindstone (or something like that)...

Coming together...

I can really see the pieces of Clique Space(TM) come together. I've completed the Agent Device engagement process, the projected Element contains tokens thing, and I've been retrofitting a class that manifests an Element's identifier (ElementIdentifier) to see if I can architect a way to discriminate between different identifiers so I can (inter alia):

• indicate an Element's serving Agent Device through its EngagerParticipantIdentifier.
  
  
• prevent an errant (or nefarious, or even perhaps merely a narcissistic) user from giving an identifier a specific value; an identifier's value has no inherent meaning beyond its ability to uniquely identify an Element, and each Element is assigned an identifier who's value is currently a 40 character randomly generated upper-case alphanumeric string when the Element is created on it's serving Agent (or, indeed, Client) Device.
  

Other things like the co-evolution of the Agent and Client Devices, the growth of the number and variety of the Elements and the growth of the complexity of the interactions between the Agent and Client Devices continue to inject increasing functionality into the implementation. As the system's complexity evolves, I observe the data model moving from a simple implementation to a more abstract and generic one. I introduced Java generics about a year ago, and this move has (hopefully for the better) proven indispensable in expressing the relationship of the Agent and Client Device's specific use and manifestation of the generic data model.

Just yesterday, I completed the projected Element's existential life-cycle by coding a method that "unprojects" Elements given an Element's identifier, and the delegate identifier of the serving Agent Device through which the given Element token has been obtained. It works. I can remove any Element describing any part of a projected Client Device's structure from any Client Device through which the command to unproject is issued. I am entirely confident that implementing a robust identity/anonymity mechanism using this ability to unproject any projected Element is not far away.

Clique Space(TM): An engaging development.

About 15 minutes ago, I believe I have successfully managed to get two Agent Device's to exchange information about the other, and in so doing, acquire information about each other that facilitates further communication.

I have called this the engage process. There is an opposite - the disengage process - where two Agent Devices formally break this relationship and mutually forget about their association with the other. The disengage process hasn't yet been implemented, but I'm pretty sure it is much easier to implement than the engage process.

While engaging and disengaging are a device-specific thing (specifically Agent Devices), this process uses the basic Clique Space data model, with perhaps some liberties. It's a fairly straightforward process; two Agent Devices create information about each other on their "local" Agent Device Clique Spaces, and then mutually exchange information each has created about the other along with information about themselves by creating "foreign" Agent Device Clique Space copies of the other's local Agent Device Clique Space. The process requires that one of the two Agent Devices be the "initiator" and the other be the "responder", but once the process is complete, it is completely symmetrical; one cannot determine which device was the initiator and which the responder simply by inspecting the relationship artefacts on each Agent Device.

So there you go. Now that the Agent Device engagement process has been (one hopes) stabilised into a fully functional realisation, I will begin concentrating on the Agent Collaboration.

Does this Clique Space(TM) thing work yet?

Probably not, but this last commit has seen another yin receive a yang, and still, no unresolvable paradox.

Yesterday's tale of woe was bleaker than today's reality.

The Client Device now appears able to disband under the "projected Element contains tokens" architecture that went in on 31 May. Part of any development process means travelling down garden paths, back-tracking, and changing direction, so although things are still a bit rough, it appears that the Client Device can listen to any Element the user has access to. This code is beginning to look tight, and I'll tighten it yet.

It has also been a year since I started using SVN, having committed revision number 453.