Three-stage delegates: redundant?

My Clique Space(TM) POC continues to evolve, and the question of whether or not the use of the "three-stage delegate" paradigm for the administrator client should be revised.

The trigger for the consideration of this question was the realisation that the Identity is an Element that allows a user to group multiple Connections with multiple Affiliations so that a Participant may be generated from a combination of Connections and Affiliations (at least one of each is required) whenever a particular user takes the opportunity to express themselves as such in a Clique. A user's identity is hence, a palette of different potential devices and roles that the user may elect to collaborate with. Very much (I'd say precisely) what an identity is in real life - a collection of different guises and means of collaboration that an individual may choose to represent a presence to others. Any user may decide it is a good idea to have multiple identities, and should be able to do this by creating multiple Identities; each of which are able to be customised by the user to shape their presence for different purposes.

Now, this realisation (Identities possessing multiple Connections and Affiliations rather than being an association of one of each) needs some rework in how the administrator client connects to an Agent Device. Currently, the Connection, Identity (known as the Active Affiliation at the time it was put in the patent), and the Participant uniquely represent the "access level" of an administrator client so that to connect the administrator client, one had first to obtain the delegate Connection, followed by the delegate Identity, and finally the delegate Participant. The projections of these delegates each supplied an RMI stub which identified a delegate server on the Agent Device. This was a good way to separate administrator client connection into a three stage process. It was especially good to do because the Participant couldn't be developed without the Identity, and the Identity couldn't be developed without the Connection. Splitting this process into three stages facilitated early development of Clique Space.

Now, I 1: find that obtaining each of these delegates in turn is probably too involved. When an administrator client connects to a Clique Space, a Client Device's Participant is given to the administrator client to represent the administrator client's participation in a serving Agent Device's Clique. The Agent Device's Participant is generated for the Agent Device nominated as the serving Agent Device: the Agent Device that will handle messages that originate from the connected administrator client, and this will be, in all currently realisable scenarios, the Agent Device through which the administrator client has obtained the Connection from.

Additionally, because the Identity can contain multiple Connections, such an Element must 2: necessarily exist independently of a Connection of any administrator client. This means that the Identity must exist, like an Account, an Account Profile, a Media Profile, or an Affiliation, as an Element which is independent of any device.

So, both of the above points leads me to the following conclusion: drop the notion of the delegate Identity and the delegate Participant because both these objects are not necessary any more. Instead, keep the notion of the delegate Connection so that when an administrator client first connects to a Clique Space, it will elect to connect under a certain user's Account identifier and Identity, and it will receive a delegate Connection if it is successful. Upon receipt of its delegate Connection, it can query the serving Agent Device for any other Elements, including the user's Account, the user's Identities, the Client and Agent Device's Participants of the serving Agent Device's Clique in which the given administrator client is the Owner, any other Connections, and Affiliations associated with the given Account, any Media and Account Profiles that may either be components of any of the respective Affiliations and Connections, and any other Element on the given Clique Space which the user, by virtue of the Client and Agent Devices' limiting constraint affinity allows the given administrator Client to know of.

So, this is the way that things are going to change. By removing a mechanism that was useful for a time, but is now an impediment because 1: it appears too complicated and 2: it actually appears to be an incorrect solution, this change moves the implementation closer to the concept envisaged in the patent.

This musing is a deliberation over some of the pragmatic implications of a deliberation I had earlier.