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.
- 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. - 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. - 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. - 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. - 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. - 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.
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.
No comments:
Post a Comment