Sunday, October 17, 2010

The unknown known and how some people suck.

I'm listening to a broadcast from the US National Public Radio taken from a feed of the Australian national broadcaster (ABC) about how ideas and concepts involve networks and the building of ideas on top of one another. Apparently, this is innovation.

Personally, I think a lot of what is being said on this program are ways to rationalise reasons for why the individual has no claim to one's ideas. It's all a big hippy free love thing. Anyway, to steer me back to the point of my topic... I am updating the count of the types of knowledge... there is relevance in the fourth: the unknown known.

That is, there are those facts we know; there are those facts we know we don't know; there are those facts we don't know we don't know. I also include facts that we don't know that we know. It is this fourth fact that yields epiphany, and is heralded as innovation.

I believe that for several years before the winter of 2004 when I joined the dots whilst jogging, I had the requisite pieces of the Clique Space(TM) concept in my mind; all that remained was my realisation that they were coherent. So, I had been working on Clique Space for some time - I remember wistfully mulling over various pieces of concept soon after my stupid boss's boss roused me out of his office when he couldn't give me a reasonable justification for vetoing my boss's approval for me not to have to commute to Sydney 5 days per week.

People can really suck. But their suckiness can drive inspiration. However, that suckiness can also rid the individual of their claim to their own inspiration, and assign this inspiration to something called a 'network'.

Some people can act most perniciously.

Thursday, October 7, 2010

Clique Space(TM) is alive an kicking, except for...

Today, I committed revision 306 to my svn code base.

Apart from the fact that I have an implementation that is 1. next to useless; 2. ugly; 3. fragile and inflexible; 4. possibly leaking memory like a gauze-less sieve; 5. without transaction and thread control; and 6. insecure, I reckon to have proven about 75 to 80 percent of the core concept. The only component to remain in fantasy land is the full implementation of the Enabling and Limiting Constraints, although the latter has been partially implemented.

The Clique Space view, while being part of the concept that I envisaged, is apparently not part of the concept that I have patented. Again, it appears that I'm not rich enough to afford to protect myself.

So, to explain these numbered points.
  1. Next to useless.

    This might sound derisive (in a way it probably is) but this is actually progress from the state of fantasy that one would behold had I not have started this exercise. This is also a relatively accurate statement considering the fact that Clique Space is customised to work with devices through Media Profile customisations. Considering that someone told me there are about 4 million types of devices in this world (that's probably growing at an exponential rate based somewhere around More's folklore), the fact that I have implemented no less than two (the Clique Space administrator Client Device and the Agent Device) means I've got quite a few device types to make Clique Space generally useful.

  2. Ugly.

    Currently, Clique Space has only a console interface. I have very clear ideas about how I want Clique Space to look, but at the moment, I still have too much application logic concerns to direct any focus this way. By console interface, I probably mean an interface that has no proper display output at all: just many strategically placed system.out.print/println() statements; input, via the administrator Client Device (where it is supposed to be) is through a simple command dialogue box.

  3. Fragile and inflexible.

    Clique Space can be considered fragile and inflexible for three reasons. Firstly, in so far as my prototype can behave in all the ways it will when fully developed, it indeed does a great majority of these things. However, there is currently no respect paid to human error or interference introduced through a noisy world. Anything unexpected that happens to Clique Space while running usually leaves the associated Agent Device and the zero or more connected Client Devices in an inconsistent state. There is currently no way of dealing with exceptions but to restart all devices involved.

    Secondly, a Clique Space is a collaboration of one or more Agent Devices. Only one Agent Device (the Clique Space owner) can currently realise a Clique Space because the Agent Collaboration has not been implemented. I am about to direct my immediate attentions to the implementation of the Agent Collaboration.

    Thirdly, both the Client and Agent Devices operate on the same host. Although this is a relatively trivial issue (it just means replacing the hard-coded localhost entry with a configurable IP address in most circumstances where the devices are using TCP/IP as their transport) the development work that still remains to be done keeps me away from truly distributing my prototype on different hardware devices.

  4. Possibly leaking memory like a gauze-less sieve.

    Simply, I have been programming functionality in to the system. At this moment, the Client Device appears to have better memory hygiene, but I'm just getting the thing (the whole Clique Space thing) to work. Maybe some day I'll get my hands or someone else's hands to get the Agent and Client Devices to properly clean up after themselves.

  5. Without transaction or thread control.

    An Agent Device will not serve multiple Client Devices simultaneously, nor is it capable of reversing the actions of one Client Device if something goes wrong. The Agent and Client Devices communicate to each other using a collection of RMI servers set up on each. Although multi-threading is implemented by default through the RMI mechanism, no consideration has been paid to contention or deadlock. These are more specific cases that demonstrate the system's current fragility and inflexibility.

  6. Insecure

    Clique Space will, of course, use whatever the latest information security mechanisms exist. Clique Space will, of course, be continually updated to use tighter such mechanisms as they come into being. At the moment, Clique Space has nothing. Separate Clique Spaces will be capable of federation into a large neighbourhood of distinct Clique Space domains, and Cliques that might form in one will (depending on mutual federation polices) be able to span two or more Clique Spaces. Secure federation is perhaps a while off right now.
To sum, I am beginning to see the shape and the potential of a fully developed Clique Space system, but there is one hell of a long way to go.

If you like this idea, and you think you might be able to help me, then please leave me a private message. I'll get back to you. Try me on my email address; owen dot paul dot thomas at gmail dot com or my phone number +61 401 493 433.

I also have a Skype address: "owen.paul.thomas". I'll fairly chew your ear off about Clique Space.

Tuesday, October 5, 2010

More on Clique Space(TM) and the self.

Again, it can be said that Clique Space defines the self. This "selfness" quality is asserted primarily through an Account.

Clique Space Accounts are used to express the individual operator behind adaptations of the how the user wishes to represent themselves to others; collections of Client Device Connections and role-based Affiliations. A connection is the first access level to a Client Device in a Clique Space. Such a Client Device may activate itself, or may be activated by another Client Device which is a Participant, and has the ability to activate such a Client Device through a Client Device which is registered in a Clique as a Participant with the Clique Space Owner. Usually such a Active Affiliation will be granted through authorisation from an Active Affiliation of a Clique Space administrator Client Device that is being used by the same Account (denoting the same operator) as that to which the access is being granted.

Clique Space, per se, is useless. Any Clique Space only becomes useful when it can model the interactions over different media as described in its Media Profile hierarchy. The more comprehensive this hierarchy, the more devices can be modelled, and hence, the more useful a Clique Space can potentially be either to those who choose to connect directly to it, or to those who choose to participate in Cliques that span their own Clique Space and the specific Clique Space in question. Connections associate an Account with a Media Profile, and one Connection represents one particular Client Device instance in Clique Space.

Affiliations are defined by associating a particular Account to (at least one, but possibly more) Account Profiles. Account Profiles are primarily the way by which privacy settings for a particular Account can be Asserted. An Account Profile hierarchy can define, for instance, a business hierarchy. Instances of Affiliations can be (depending on the permission settings - expressed through Limiting Constraints - of the Account Profile to which a particular Affiliation may associate) freely assigned to different Connections through the process known as Client Device activation. Each Active Affiliation is the apex of the set of six elements just described: Active Affiliation, Connection, Affiliation, Media Profile, Account, and Account Profile. These six elements aggregate a collection of Limiting Constraints.

Activation is the second access level; it is an association between a particular Connection and a particular Affiliation, and is itself, represented with an Active Affiliation. A Client Device that holds an Active Affiliation can, depending on the compatibility between Limiting Constraints between the two Client Device stacks, participate in Clique Space with other Client Devices which are likewise active.

Participants are the seventh element of the Client Device stack and are the third and final access level to a Client Device. Participants represent a Client Device's membership of a particular Clique; a group of collaborating Client Devices which are being modelled. The Clique's media is a collection of Enabling Constraints (parameters through which Limiting Constraints can shape) shared by all Client Devices. The media is determined by one of the Participants known as the Clique Owner.

A UML diagram is so much more compact.