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.