Wednesday, May 30, 2012

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.

Monday, May 28, 2012

A rejected mail group posting.

This blog is primarily about Clique Space(TM). However, in this post, I'm going to talk about one of the motivations that contributed to the conception of this Clique Space thing: how a society appears to continually want to thwart my attempts at my finding a productive place in it, and how truly pernicious society can appear to be in perpetrating these ends.

Today, I tried to post the following contribution to a mail group. This message contains two ironies:
  1. IBM assert how they're top notch A1 in terms of workplace diversity and anti-discrimination by simply manoeuvring around the spirit of laws which were conceived to help people.
  2. in telling this story, I may risk divulging matters held in confidence by IBM in regard to the nature of their manoeuvres, and how this disclosure might render me liable for prosecution on these grounds.
Anyway, if IBM might ever feel so disposed, then here's their opportunity. The content of the letter I'm quoting here was judged too contentious for posting by the group's moderator.

  • I find the fact that some of the cases given in [US case law] parallel my circumstance to some extent. I have made several applications to IBM and highlighted to them to consider a neuropsychological disability (acquired brain injury) in my case so to provide me with a part-time telework position.

    IBM specifically advance themselves as an employer who doesn't discriminate against disability, yet I find that I have continually been declined jobs when I have applied on these grounds, regardless of the fact that I was in IBM's employ before I received my diagnosis. I had to leave because of the fact that my employment conditions played against my disability, and so my subsequent applications were (and are) an attempt to regain employment with IBM under circumstances which would be more favourable.

    This is a case of IBM playing to the letter of the law rather than the spirit: IBM would not even attend a conciliation meeting with the Australian Human Rights Commission when I made a complaint of discrimination against them. The fact that IBM cannot be compelled to attend these meetings illustrates how the spirit of Australian discrimination law can be evaded while companies like IBM can make motherhood statements about how they value workplace diversity.

    I don't know whether any of what I have disclosed here is confidential, but if I have disclosed anything like this, IBM might now try to sue me for disclosure of confidential information. They would be suing a man who, owing to the fact that he cannot secure a productive job under favourable terms, is a pensioner. So good luck there.

    I regularly draw the attentions of IBM to my frustrations in passionate letters to their recruitment department.

Sunday, May 27, 2012

Deliberating constraints... once more.

Clique Space(TM) is a constraint based system. Constraints are properties: Enabling Constraints are properties which are contained in Media Profiles and give Cliques their Medium; Limiting Constraints are properties which can appear in any Element and give Cliques their mode because they are values which associate with specific Enabling Constraints in a Clique's Medium. This combination of Enabling and Limiting Constraints can be used to control the devices of the collaboration being modelled by the Clique.

Although Limiting Constraints carry expression in Participants, they can be assigned to any Element so the underlying device-specific collaboration's participants can be shaped in accordance to the context served by a particular Element. For instance, if a Limiting Constraint is assigned to a particular Account, that Limiting Constraint will find expression in any device of the appropriate medium used by the Account holder - the individual "self" that is operating the device. If the Limiting Constraint appeared in an Account Profile, that Limiting Constraint will find expression in any device of the appropriate medium in accordance with some role-based hierarchy of organisational privileges. Finer levels of device control can be obtained by assigning Limiting Constraints to the other five Element types.

Because the Agent Device is a device like any other, Clique and Element access and general user interaction (governed by the mutual consent of the individual users rather than the Clique Space system itself) can be controlled through the application of Limiting Constraints to a Clique's Medium's Enabling Constraints of any device so connected to a Clique Space by any individual Account holder who so connects their devices.

At least, that's the intention. It's coming together slowly, and my deliberations currently revolve around the implementation of this constraint mechanism. There is to be some remodelling of the existing pieces. Identifiers will become mere properties. This appears to imply somewhat of a simplification of the implementation in that properties become the exclusive units of transmission. Properties will contain their own generic transmission mechanism, and hence identifier transmitters might be removed. I appear to sense that properties will natively replace the current precis proxy objects, so the concept of the precis might be dropped too.

All this simplification may free up a few names that I can re-use as I intended originally. I am glad to see terms finally take forms closer to the original intent, and this is as much because a simple system is better than a complex one than it might be vindication of my original concept.

Thursday, May 17, 2012

Deliberating Constraints... again.

I believe I have almost developed a UML diagram of the structure which will be implemented to express the Enabling Constraints and Limiting Constraints. This structure has perhaps a little more to it than I first thought, but not much more than given in the patent spec.

I'm probably going to begin coding this structure within the next few days; there are perhaps still a few small questions to be answered before a sufficient charge can be released over the implementation.

Sunday, May 6, 2012

More about Client Devices

Again, my definition of the Client Device needs clarification, and this entry is meant to mark a point at which the clarification will take place.

A Client Device as an abstract notion is an ensemble of Connections and Affiliations relating to a singular Identity. An Identity relates to a singular Account, and all the component Connections and Affiliations are registrations against this same singular Account. A particular instance of an Account, a Connection, or an Affiliation may be referred to in zero or more Identities. Identities may have zero or more Participants, but a Participant refers back to a singular Identity.

Therefore, a singular Identity, and its component Connections, Affiliations, and Participants comprise the abstract notion of a Clique Space(TM) Client Device.

I have also historically referred to the Client Device as any device which is Clique Space aware. In these cases, I have also referred to these devices as possessing a device activity View or a device activity stream persistence mechanism. In the future, I will try to avoid referring to the Client Device in this way. Any device other than the Agent Device will be referred to simply as a device, and if it is pertinent to state that the device has a view or persistence mechanism in the particular context, this will be probably be mentioned. The device permitting administration of Agent Devices and Clique Spaces being developed in parallel to the Agent Device will henceforth be referred to simply as the Clique Space administrator device or simply the administrator device if the context permits the term Clique Space to be dropped.

Is the undisclosed Element the result of an implementation flaw, and if so, has this flaw bitten me on the bum?

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.

Saturday, May 5, 2012

Deliberating Constraints...

As the Clique Space(TM) implementation evolves and matures, I feel the growing necessity of entertaining the notions of Enabling and Limiting Constraints. Although these pieces of my concept exist in the implementation, a realisation approaching the intended purpose is still wanting.

So, my patent spec describes two main types of constraints: the Enabling Constraint - one of these describe some functional parameter of some type of "real" device; and the Limiting Constraint - a value that an Enabling Constraint can take. Enabling Constraints are contained inside Media Profiles because Media Profiles describe functionality of a specific real device type, or, in the case where a Media Profile hierarchy is used to describe a real device, an individual Media Profile node in this hierarchy can be used to describe some set of functionality that can be used to distinguish, categorise, and collectively, to build, different real device variants. Limiting Constraints are contained inside any Element, including Media Profiles, and are set by device vendors to shape the device's function according to some physical limitations, by users in accordance with personal identity preferences, by organisations in order that device behaviour be reflective of organisational goals, or Clique Space administrators so to maintain a Clique Space's stable functioning.

Although any Element can contain zero or more Limiting Constraints, it only appears necessary and consistent to model and control device state through Limiting Constraints inside the Participant Element because the Participant represents a real device as it is participating in a real collaboration going on in a real medium in the real world; whatever all that - determined by possibly one or more, but at least one Media Profile hierarchy - might actually mean.

Now that I've set this stage, I can talk about the contents of my current deliberations...

From the blather above, one can surmise that an Element is a collection of Limiting Constraints which express values that certain device properties can take, and that a particular type of Element - the Media Profile - contains Enabling Constraints which expose those properties to a Clique Space. Additionally, for this deliberation, it is also necessary to consider that all of these Elements have specific relationships to each other. For example, a Connection is an association of one or more Media Profiles with exactly one Account.

Clique Space is realised through the Agent Device. An Agent Device is a device, and like any device, the Agent Device can be modelled in a Clique Space. Because Clique Space expresses the properties of a device as a set of Enabling Constraints, relationships between Elements - as in the above example, a Connection's Media Profiles and Account are components of the given Connection - can be expressed as Enabling Constraints.

Up to now, economy has mandated I declare specific instance variables for these defined relationships. However, because these relationships can be expressed as Enabling Constraints, the time has come, perhaps, for me to really go to work on progressing the implementation of these Enabling and Limiting Constraints. Time might be ripening for me to work out a protocol for determining when to check for constraint affinity as well as the subject of the necessity of a call-back mechanism that could be used to programmatically compare constraints according to what is necessary for particular devices.

This deliberation kind of fits in with my want to test the administrator Client and Agent Device's implementations of the undisclosed Element and identifier: part of the deliberation point of my previous post. Having now just implemented these, I cannot actually see them in use because the Agent Devices don't currently create or transmit undisclosed Elements or identifiers to other Agent Devices, nor do Agent Devices project undisclosed Elements or identifiers to administrator Client Devices. All this is because there currently exists no mechanism to determine that a receiving Agent or administrator Client Device has insufficient constraint affinity: part of the deliberation point of this post.

We'll see where I'll go from here... I'm pulling the draw strings tighter on this proof-of-concept; in some sense, I'm watching disparate pieces finally come together.