Last nights dreaming awoke me to the possibility that there is a flaw in the Clique Space(TM) POC implementation. The flaw has its origins in the representation of Elements' properties through various other instance variables; the possibility of its implications have only become evident since I started entertaining the storage of all Element properties as Limiting Constraints in accordance with the patent. Hence, the possible spectre of this flaw has only become evident since my last post.
This blog entry is a tale of how earlier implementation compromises may have resulted in the creation of redundancies. However, maybe this flaw couldn't be easily avoided, but the solution that I am thinking will be necessary is probably near ideal provided one spends a lot of time re-engineering and simplifying the existing implementation.
The problem.
Currently, I believe without checking the code, that there are no less than ten distinct Element sub-types. The necessity to create these sub-types is due to implementation considerations revolving around the seven Element types given in the patent: Account, Media Profile, Connection, Account Profile, Affiliation, Identity (erstwhile Active Affiliation), and Participant. In as far as each type combines certain other types to achieve the well-defined purpose of the Clique Space concept, expressing these Element sub-types as various subclasses in the implementation appears to be the correct approach. Each of these ten Element types have a corresponding identifier type.
However, at one stage, the internal mechanics of the Java implementation language environment appeared to suggest to me that some further subclasses of the Element types were required for different media. At one stage, I coined the term "Media Profile spine" to represent a collection of four Element types (Media Profile, Connection, Identity - known as the Active Affiliation at that time, and Participant) as a structure that required customisation for different devices, and these customisations would extend through to other devices as they were made "Clique Space aware". However, after reviewing the intent of the spec some time after thinking customisation of the Media Profile spine was necessary, but some time ago from now, I recalled that Enabling and Limiting Constraints were intended to remove the necessity to derive subclasses for Elements in accordance to this need. I realised this at around the same time I deduced that the Active Affiliation functioned as the focal point of a user's identity in the formation of a Client Device structure, and hence gave this Element the name Identity.
I was very happy to realise all the above because additionally, I realised that my implementation would suffer a significant simplification. I could remove consideration of dynamic class loading from the implementation of the core data model in Java, and could be reasonably happy to know that there should be no particular near-term concern about dynamic class loading.
The implications for all this are great. However, I have travelled quite far in my implementation, and I have come to realise that those devices which I have thus far developed customised Media Profile spines for (the engager, the collaborator, the Clique Space participtor, the administrator client and the Agent Device among other less significant customisations) have created a concern about the communication (transmission and projection) of these Element types, and this concern also relates to my realisation last night that the undisclosed Element appears to be a red herring.
The undisclosed Element was intended to be a proxy for all other Elements when a customised Client (or an Agent) Device queried an(other) Agent Device for an Element represented by a given Element's identifier, but received nothing. Unfortunately, this solution is not on the mark. When a device acquires an identifier, it does in fact know two things about the Element identified by it; 1: the device knows the Element's identifier (this may appear circular, but indeed, this is information) and 2: it knows the type of Element - of which, in accordance with my above recollections, there are ten. So, creating an undisclosed proxy element disguises these things. It also creates a presumption which, at some time, needs to be dropped if there comes a future time when the Agent Device or View enabled device acquires "some" additional information about the Element.
The better way to go about things would be to create the Element. However, with all the Media Profile spine customisations already implemented, there are around 30 different Element sub-types that are identified by about ten different identifier types, so not enough information is disclosed when an identifier is acquired to create the specific Element type.
The (compromise (?)) solution.
The identifier transmitter could contain the class of the Element identified by the identifier instance. This will allow the POC to instantiate the correct type of Element (a "shell") to which the identifier relates. As a device acquires more information about the Element conveyed through subsequent acquisition either by transmission if the device is an Agent Device, or by projection if the device is an administrator or other View enabled device, it can store this additional information (additional Enabling or Limiting Constraints) in this shell.
The (ideal (?)) solution.
The Element shell approach appears to be the ideal solution. There should be at most the same number of Element types as there are corresponding identifier types so that each identifier and identifier's transmitter, identifies the specific Element type so the identifier transmitter doesn't have to convey the specific class to be created. In most circumstances, the undisclosed Element and identifier should be scrapped.
There still appears to be a use for the undisclosed Element. The undisclosed Element does appear to have use in a View enabled device where the undisclosed Element is substituted for any missing components of a Client Device's structure when that structure is being rendered to, or specific Elements are being described by the View enabled device's operator.
I appear to have three German followers now, or perhaps I have one German follower who thinks my deliberations so interesting that the decided to read this entry three times.
ReplyDelete