Introduction - The Current Interface - More Complicated Control - The Astrophy Interface - History of the Astrophy Project
This is very much a work in progress. And the progress has basically stopped. I welcome suggestions, please e-mail them to me at ian@hixie.ch. There is a great deal of text commented out, too, that you can read. However, much of the text on this page is speculation and musings, and some of it contradicts itself, and I really have not the time to update it properly. Sorry.
I firmly believe that eventually, everything will be on the internet. Your washing machine, your oven, your alarm clock, your clothes: everything. (Not consumables. But more on that later.)
This is not that far fetched: With IPv6, there are over 1000 IP addresses per square meter of the earth's surface and in time, it will become affordable to run a (low bandwidth?) network over the house's mains power supply (using the mains power supply for Internet connectivity has already been done).
It will become trivial to install little microchips which simply use the mains as their power source and network cable, and control the devices to which they are attached. For example, a light fitting would support "on", "off", "set to 26% intensity" and "report status". The light fitting could then be automatically, regularly (like once a day), polled by a computer somewhere, and when the "report status" responds with "filament dead" a replacement could automatically be ordered and the housekeeper would be informed by e-mail.
This document first describes how the current systems (eg, switches) could be implemented using such a network. I then go on to describe an interface I started developing which would, in my opinion, work very well in this environment.
WARNING! This document is a mess. I just write bits down when I think about them. Hence, it may be a little self-contradicting in places. There are also large sections of text that have been commented out as I am not sure about them. Feel free to read them.
The simplest interface would be what we have now. For example, with the light, to turn a light on you turn a switch on, and to turn the light off you turn the switch off. Currently, the switch and the light have to be hard wired into each other: the switch controls the light because it actually cuts of the electricity to the lamp.
What if, instead, the switch were merely to send a message to a central server, over the network running over the mains, and the server was then to tell the light to switch on? That way, the switch and the light need not ever come into physical contact, so long as they are both on the network.
Servers could be set up to map switches to specific lists of lights, and then making four switches all control the same eighteen lights would require no more than making sure the four switches and the eighteen lights were all on the network. No longer would wires have to connect the eighteen lights and four switches together (and in relatively complex circuits, too!).
Doors could be wired into the network too, providing functions such as "report status" ("open", "closed", "locked"...), "lock", "unlock", and even, should the door have a decent motor installed, "open" and "close". Also, the microprocessors could be configured to automatically notify the central server when it was opened, locked, and so on.
Currently, shops frequently have systems that ring a bell when the door is opened. This always requires a (dedicated) physical connection between the door and the bell, which is a pain if the bell and the door are in different rooms or even different buildings. Using the network system described here, one could simply have the door notify the bell over the mains (via the server), making the whole setup more portable. Also note that this means that the bell can be moved with no problem, one need only make sure it was still plugged into the mains to ensure that the bell still rang when the door was opened.
Imagine this: you are in your room, and you want to turn off the main light. You merely say "light, off", and bingo: the light goes off.
What about this: you are at a social function two towns away from your home, when you remember that you left the oven on. You tell the local computer "my, home, kitchen, oven, off", and the problem is solved.
You may be thinking that it would be much easier to simply say "Computer, please turn my oven off". Unfortunately, it is a fact that the English language (and in fact all other human-native languages) are very ambiguous. Almost every simple command given can be misinterpreted. Computers are currently not very good at understanding what one means... which is what requires us to develop, as an interim solution, an unambiguous but straight forward interface.
Could an interface be devised that is completely unambiguous, can control any appliance connected to the network, and yet only requires short sentences?
Well, in the words of Dr Bullett, my Quantum Mechanics lecturer here at Bath University: "And the answer is of course yes otherwise I wouldn't be wasting a Friday lunchtime telling you about it".
The Astrophy Interface, simply put, is an object orientated tree. Each node consists of a series of methods, properties, children and links. For those who are not familiar with those terms, a quick explanation is in order.
Just like the real thing, a tree is structure which starts with a single branch (the root) and splits up into smaller and smaller parts.
The directories (folders) and files of most computers are ordered in a tree.
The Astropy Interface could use a tree similar to the following:
root
|
+-- universe
| |
| +-- [solar system, eg "Sol"]
| | |
| : +-- [astronomical object, eg "Earth"]
| | |
| : +-- [geographical area, eg "Switzerland"]
| | |
| : +-- [location id, eg "CH-1945"]
| | |
| : +-- [place name, eg "Mike's house"]
| | |
| : +-- [etc..., eg "Alice's Bedroom"]
| | |
| : +-- [appliances, eg "Light"]
| |
| +-- [appliances, eg "Radio"]
| |
| :
|
+-- time
| |
| +-- [exact time, eg "1998-11-28T12:24Z"]
| | |
| | +-- appointments
| | |
| | +-- holidays
| |
| +-- now ==> link to node of current time
| |
| +-- ...
|
+-- people
| |
| +-- Linus Torvalds
| | |
| | +-- information
| | | |
| | | +-- Linux Project
| | | |
| | | :
| | |
| | +-- plan
| | |
| | :
| |
| +-- Joe Michael Straczynski
| |
| :
|
+-- filesystem
|
+-- clipboard
|
+-- local
| |
| +-- bin
| +-- var
| +-- opt
| +-- tmp
| +-- ...
|
+-- ftp
|
:
So, for example, to tell the Astrophy Interface to turn the light on in your room you could say "Root, Universe, Milky Way, Sol, Earth, Switzerland, CH-1045, Mike's House, Mike's Room, Light, On". In that command, all but the last item are names of nodes, and together they make a path to the node that represents that light bulb. The final word, "On", is a method: a command that tells the light to turn off.
Now clearly, that is a very long chant to recite if you want to turn the light on in the morning when you are half asleep. So, in addition to the tree, the Astrophy Interface also has a notion of your "location" in the tree. That is, you are at a particular point in the tree when you are using it: you do not have to give the name of every node from the root.
So, if your current location is:
root, universe, milky way, sol, earth, switzerland, ch-1945,
mike's house, mike's room
...and you say "Light, On" the interface would assume you meant the light that is a child node of the node given by the above path, that is, the light in the room.
I haven't yet thought about this.
The astrophy system is interface-independent. (Ironic, since it is called the "Astrophy Interface"... maybe I should revise the name...) However, I have some ideas about how different interfaces could work.
If the addressing is by keyboard, then
/ /: Thus, to call the current node's radio's volume's increase method with parameter "25%", you would type
radio/volume/:increase 25%
If the interface is voice-control, then the addressing scheme will be more complicated. The main problems I have are how to separate each token making up the path from the token representing the method from the method's parameters. The easiest way would be using keywords, but I don't like that very much.
Also, I haven't any ideas how to cope with properties (those are just an idea for the moment, my Windows command line implementation didn't even begin to have support for node properties).
The tree is object orientated in its implementation. For
example, if the base class upon which all other nodes are based
supports the "where am i" method, then all nodes do.
Similarly, all nodes that implement the filesystem side of the
interface would be derived from a file system base class, which might
implement elementary clipboard facilities, thus the entire file system
would automatically support a clipboard.
Note how this means that if a link is implemented in a base object,
then all nodes that have that object as one of their ancestors will
automatically support the link. This may not sound that important, but
it is how the my link works everywhere (and brings the
user to the object representing the user).
Once upon a time, a few weeks before I decided to switch to Linux in fact, I started writing a command line interface for Windows. However, it was different to what I've seen before in one major respect: it was object orientated. That is to say, you navigated a tree structure, and to change things you would change a node's properties (attributes), and to do things you would execute a node's methods. (I was also going to allow a third type of "thing", which was a link (like a symlink in unix) to a different part of the tree).
Since it was implemented in an OO way, many of the methods were
common to all the objects. For example "children",
"methods" and "where am i" were commands
common to all objects (listing the node's subnodes, methods and the
exact path which led from the root to the node respectively).
Another idea was that internally, all file system parts of the tree would use the same interface (they were all derived from a single largely abstract class) and so they would allow simple cut and paste across file systems, be that from an http connection to an ftp one or to a local floppy or whatever.
Of course, ideally this would have to be implemented at the kernel level or below, so that programmers gain from this too.
I never finished this project, in fact, it never got past the prototype stage, since I quickly realised that I was going to switch to Unix and so writing a Windows program at that stage was silly. However, I am planning on returning to this project at some stage in the future.