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.

Another causal loop. A conundrum. Another crossroads. A possible compromise.

Just as things looked easy, I hit a snag.

The (administrator) Client Device listens to other Elements from the Agent Device to which it is connected. The Client Device does this by registering its interest on these Elements from one of the delegate Elements on its Client Device spine so these Elements can be projected onto its view for the user to observe, or persisted on some storage medium for the user's record; the primary vertebral Element (and the one from which this conundrum emerges) currently being (currently is part of this problem) the Client Device's Participant of its serving Agent Device's Clique.

It's not really a problem. Rather, I feel that it could be a crossroads, or then again, the problem might only be in a misapprehension of the nature of Clique Space's(TM) domain in the current implementation. Certainly, I feel that I can solve (or rather, I merely need to find where the correct solution exists to) this problem.

The problem is thus:

The administrator Client Device listens to Clique Space activity by registering its Participant in the serving Agent Device's Clique as a listener to another Element the Client Device's operator is interested in. The serving Agent Device's Clique is a bipartite Clique which is created using the Client Device's Active Affiliation and the Agent Device's Active Affiliation from the Clique Space to which the Client Device is seeking Participant access. The Client Device's Participant is this serving Agent Device's Clique's Owner.

Now, although I thought the importance of the serving Agent Device's Clique was coincidental in the Clique's formation, it also appears that the agent Device's Clique's structure appears to be of great importance to the way the Clique disbands.

Currently, I don't believe I have a full appreciation of the problem, but maybe all I need is a sufficient appreciation of it.

When one disbands a serving Agent Device's Clique, it appears that the Client Device must be the owner of the Clique in question. Consider for a moment, what currently is not the case. If the Agent Device was allowed to own the Clique, the following circular relationship would appear to hold: which Participant does one remove first? The Agent Device's Participant (the Clique's Owner), or the Client Device's Participant; the delegate participant for this Client Device? If the owner is removed first, the administrator Client Device loses information about the Clique (although removal of a Clique's Owner means the Clique is disbanding and therefore retaining information about a Clique is not necessary) before it loses its delegate. If the Client Device's Participant is removed first, the Client Device loses its delegate before the Clique's projection is removed (although removal of the Client Device's delegate means that the Client Device has lost Participant access to the Clique Space- which is what is happening since the serving Agent Device's Clique has disbanded).

I have to make a decision, and currently, and at the moment, it is this: I will discount notions like the one described in the above paragraph where the Client Device can be represented by a non-owner Participant in a Clique of more than two members; i.e., the serving Agent Device's Clique will be bipartite, and the Client Device being served will be the Clique's Owner. This seems to be the easiest way to deal with the question of whether the owner or the delegate is removed first; if this turns out to be the wrong way to go about things, I will just have to go back and modify the implementation.