Saturday, June 18, 2011

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.

No comments:

Post a Comment