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.

... well... easier.

A milestone of sorts was achieved on 31 May. There are still a number of yins that need yangs, but I'm quietly confident of an implementation that proves the concept soon. It will be a while more before it looks pretty, but if I can keep progressing as I have, I'll soon be able to demonstrate that it works.

... and then it suddenly got very easy.

As of yesterday, it seems as though I had fit the yins with the yangs. A milestone reached perhaps?