Robust disengagemt? Hmmm...

As of about one and a half hours ago, I've been able to disengage one administrator client from one Agent Device. The question now is: is this operation sufficiently generic to disengage more than one administrator client from one Agent Device, and furthermore, is this operation sufficiently generic to disengage two Agent Devices.

The first answer is: yes! It appears that an Agent Device can engage and disengage multiple administrator clients. It does not appear to matter whether these engagements are simultaneous. Additionally, one administrator client is able to simultaneously engage and disengage with more than one Agent Device. All of this is an intention designed from conception in mid-2004 to make Clique Space(TM) useful.

The larger question of engaging two Agent Devices should be answered in the next revision. It is hoped that once two Agent Devices can robustly engage and disengage, then the proposition of constructing neural clusters of Agent Devices might be seriously considered.

It works?

A Clique Space(TM)  device appears almost to function as a quasi-autonomous agent. There is, however, one obstacle: the disengagement operation.

I've discussed this subject before in past blog entries. Any two devices that engage must necessarily disengage, but disengagement is not engagement in reverse. Instead, the process by which two devices engage each other is a process whereby structures that synchronise both (two synapses, two corresponding postsynaptic subscribers) are created; disengagement is a process where these structures are destroyed. There is no symmetry beyond this obvious necessity.

In the creation of a synapse, the two devices must synchronise the state of each other's postsynaptic subscribers created for this engagment, and this synchronisation must continue until both devices have disengaged whereupon these postsynaptic subscribers are destroyed.

I believe I have a fairly robust solution for engagement. Although the same cannot be said of the disengagement, maybe I am almost there...

Generic beauty.

I think I did something today that I might just label the "end of the beginning" for development activity on the CliqueSpace(TM) core implementation.

Something appeared finally to vault the generic structure: I discarded the notion of a "root" profile. Instead, I made the Participant implement the Media and Mode Profile's interfaces.

Many problems appeared to dissolve... perhaps.

It Works! Part 1.

Finally, after 6.5 years of coding, Clique Space(TM) works... kind of.

But that's right... it does indeed do something non-trivial. An Agent Device will now engage and disengage one or more administrator clients. I just got it working... not more than 20 minutes ago.

The synapse: works.
The service: works.
The subscriber: works.
The subscription: works.
The context: works.
The payload: works.
The transmitter: works.
The device: works.
The signal: works.
The Element: works.
The principle: works.
The root profile: works.
The Participant: works.

These components comprise most of the implementation of Clique Space's real-time manifestation mechanism. This mechanism (for Agent Device - administrator client engagements only): works.

Now, I've gotta get two or more Agent Devices to engage themselves over a Sovereign's Clique Space. That is, I've got to get Agent Devices to form neural clusters based on a secret that is never shared between devices called "That Which is Sacred"(TM... perhaps?) - the Clique Spaces that manifest Sovereigns, modelled in a Clique(TM) called the Viscera(TM).

After that, I'll:

1. try and get two or more Agent Devices from different Sovereigns to engage each other in a "Congressional(TM) (formerly known as an Agent Collaboration) Clique Space.
2. try to make devices more robust and able to reconfigure engagements in adverse environmental conditions.

I think that the real-time reconfiguration under adversity is really going to take some time to nut out.

To the viscera and beyond...

.. gotta love all this TM'ing. Well, it is mine, so mits off!

CL,I,P,O,N

A nightmare of confusion.

Recent time with Clique Space(TM) has dragged me into the dependency nightmare that is Java generics; a nightmare from which I might be awakening.

Clique Space code comes in two halves. The chassis is the basic Clique Space data structure definitions and implementation of functionality in relation to the sending and receiving of transmitters while the top half is the body of the specific implementation of a Clique Space aware device.

The halves are separated by a set of parameterised types that make the cute acronym disclosed in the title of this blog entry. The specific device implementation's body "clips on" to the generic chassis. Hence, the chassis defines these generic parameters, and the body completes their implementation. The terms used in the acronym are as follows:

• CL - The basic Clique structure and mechanisms contained therein.
• I - The Identity structure and mechanisms contained therein.
• P - The basic Participant structure and mechanisms contained therein.
• O - A more specific Participant structure relating to Owner Participants of synapses and involvements.
• N - A more specific Participant structure relating to non-Owner Participants of synapses and involvements.

The acronym using the first three of these parameterisations has been around for a while. The final two types needed to be added to or "clipped on" the end of the fist three because I wanted a way to discriminate between the Owner and non-Owner Participants of a synapse or a service or viscera as involvements. One of the prime benefits of using generics is that one can check types at compile time, thereby reducing the size of one's code (not having to guard run time type casting) and ensuring one's code has fewer bugs.

Hence, these extra two types (O and N) are used to ensure that an Owner Participant is returned where an Owner Particpant is expected and a non-Owner Participant is likewise returned when expected. This type of discrimination is important in cases where structures derived from the basic Clique (the synapse, the service, and the viscera) are being manipulated. These specific Clique structures have extra functionality because this extra functionality helps a Clique space do the things I intend it to do.

A thing of beauty.

The Viscera and the Service

I explained the function of the viscera here, so I will dispense another explanation in this entry and explain what the service is. I'll then contrast the two.

The service, like the viscera, is a Clique. Unlike the viscera, it is strictly a bipartite Clique; the owner is always an Agent Device, and the other member is an external device (which could be a View device like an administrator client which is able to view or persist Clique Space activity). External devices cannot participate in viscera because they are not Agent Devices. Agent Devices are the only type of Clique Space aware device that manifest the functionality necessary to participate in viscera; Agent Devices are the neurons of a Clique Space.

Although services are not synapses (synapses are another type of bipartite Clique) they are used where synapses connect an Agent Device with a View device. A set of synapses do not connect an Agent Device to any other type of external device other than a View device. Hence, external devices that lack a View capability are known simply as drones.

A service implements a connection between an Agent Device and some type of external device, whether that device be a View device or a drone. All external devices siphon their state into a Clique Space and accept commands from a Clique Space through one or more Agent Devices through which each device shares a service.

The basic service represents the aggregate mechanism of exchange between an Agent Device and an external device that exists beyond the synapse mechanism that Clique Space aware devices use to share information. The service may define an interface known as a service delegate which defines how external device information is exchanged between the external device and its connected Agent Device. Services are strictly bipartite because they represent the mechanism of exchange between one external device instance and the Agent Device instance that serves it.

An Agent Device can stop serving a drone by simply disbanding the associated service, while more specifically for a View device, the connected Agent Device must also disband the associated inbound and outbound synapses.

A service is not a viscera. To lightly go over that which has already been explained, a viscera is a Clique that represents all the Agent Devices that contribute to the manifestation of a Clique Space. A viscera is multipartite, and can theoretically contain an unlimited number of participants.

However, a service is a viscera in a subtle but crucial way. Just as every Agent Device obtains a non owner visceral participant to be a member of a viscera, an external device must obtain a non owner service Participant to be counted as a member of a service. This symmetry is very handy because it allows many of the mechanisms of Agent Device - Agent Device engagement to be used in Agent Device - View device engagement. The convenience of this symmetry also appears to confirm that I remain onto a real possibility with this Clique Space thing.

Viscera

Clique Space (TM). I am still doing it! It is evolving... not changing from my intentions, but growing in its ability to express my intentions.

Agent Devices and administrator clients can now engage and disengage. There are no less than three Cliques that are formed when an Agent Device engages an administrator client: two synapses and a service Clique. The two synapses are needed to represent and model the transmission channels from one device to the other and vice versa. The service represents the client/server relationship shared between the administrator client and the Agent Device.

The beautiful thing about the three Clique structure appears to be that two Agent Devices are going to use a similar three Clique engagement strategy as the Agent Device - administrator client uses, but in subtle but quite elegant way which is particularly suited to the purpose of the Agent Device - Agent Device engagement semantics. The synapses exist for the same reason: to transmit state between Agent Devices, but the service Clique is called something quite different because it has an altogether profoundly different function.

When an Agent Device is started with a new Sovereign Identity, it creates a Clique called a "viscera". I like the term; it actually encompasses the very core of the Clique Space concept: the self. Every sovereign Clique Space needs a viscera to function. The viscera discloses to every Agent Device which has joined it all members of the viscera. It allows the Sovereign to function by virtue of the fact that all member Agent Devices comprising the Sovereign are disclosed to all others through the viscera.

When two Agent Devices, being of the same Sovereign, engage one another, and the initiator engages a respondent otherwise not engaged by any other Agent Device, then both the initiator and respondent know that the respondent is joining the viscera, and the respondent (I think... this hasn't been done yet) will create and transmit the identity of a new viscera Participant back to the initiator. The initiator will advise all its co-engaged neighbours of the new member, and all these Agent Devices will do the same to their neighbours, thereby creating a wave front which will make its way through all the Agent Devices associated with the viscera.

The viscera would be comprised of very many Agent Devices (millions to billions and beyond) and would constitute the physical manifestation of an individual presence that would emerge from such a system. The term was chosen because it appears obvious to me that disbanding the viscera should be known as evisceration.