See also the paper that this talk is based on, also available in HTML.
Moore's Law is 50 years old.
Or less prosaically: Moore's Law is 33⅓ iterations of itself old.
The first time I head that Moore's Law was nearly at an end was in 1977. From no less than Grace Hopper, at Manchester University.
Since then I have heard many times that it was close to its end, or even has already ended. There was a burst of such claims this year, which caused a wag to tweet
"The number of predictions that Moore's Law is about to end doubles each eighteen months."
(I'm not sure whether I have heard more often that Moore's Law is coming to an end, or that Voyager I has left the solar system.)
As an excellent example, in February this year, almost exactly three years after the announcement of the first version, version 2 of the Raspberry Pi computer was announced.
Since three years is exactly two cycles of Moore's Law, does the new Raspberry Pi deliver a four-fold improvement?
Moore's Law says nothing about speed of computers. It says:
The number of components on an area of integrated circuit doubles per eighteen months, at constant price.
(Interesting factoid: a doubling per 18 months is almost exactly an increase of 100 every ten years).
So apart from time, there are three dimensions: price, size, and number of components. This means you have choices:
In general we have been optimising this choice: computers have been getting smaller, cheaper and more powerful all at the same time: when you buy a new computer, it is typically a little smaller, a little better, and a little cheaper than the last one you had.
Apparently the price of new home computers peaked in 1990 at $4500. We now pay typically around one tenth of that, for a much more powerful computer.
This doesn't mean we don't get a doubling; only that the doubling happens over a longer period than 18 months.
This reduction of price/increase in power has been observable since the introduction of the first commercial computers in the 50's.
(Since we're talking orders of magnitude, it doesn't matter if we're talking dollars, pounds, or euros, since they are all roughly of the same value).
Recently the first computers of the order of one unit of currency have been appearing, such as the Arduino mini.
It is on these super-cheap devices that the internet of things is predicated.
At $1, manufacturers can add them to anything.
But Why?
Wake me at 6 so I can go for a run. But not if it is raining.
Wake me in time to meet the flight. Earlier if the flight is early; later if it's delayed; earlier if there's bad traffic.
(Some of this is already happening)
A surprising unexpected success of HTML was in controlling devices, such as home routers
The problem with this approach is that it requires not only a server on the device, but also a processor for the returned values that can check them, and generate new pages for error handling etc.
But this requires not only large amounts of memory, but also significant processing power - more than you can get from a ¤1 computer
Let the device deliver its data as XML instances, and accept control values as XML instances.
Distribute the interface over the network.
Example: petrol stations in USA
Cash tills, petrol pumps, petrol tanks, and so on.
All produce, and accept, XML instances to deliver and control.
XForms are used to read off data and configure the devices.
"The future is already here — it's just not very evenly distributed." William Gibson
History: V1.0 an XML markup originally designed for Forms on the Web
V1.1: Generalised - now applications as well as forms
In preparation: V2.0 - even more generalised
Declarative
Separation of Data, Controls and Styling
Data over the network or local
Device independent controls
Diverse implementation strategies possible
Data+Constraints:
Plus where to get the data, and where to send it.
Nest thermostat
<model>
<instance id="thermostat"
resource=”http://thermostat.local/data”/>
<bind ref="ambient_temperature_c" type="decimal"
readonly="true()"/>
<bind ref="target_temperature_c" type="decimal"/>
<bind ref="target_temperature_f" type="decimal"
calculate="../target_temperature_c*9 div 5+32"/>
<submission resource="http://thermostat.local/data"
method="put" replace="instance"/>
</model>
<instance id="display">
<data xmlns="">
<temperature/>
<target>20</target>
<scale>C</scale>
</data>
</instance>
<bind ref="instance('display')/temperature" type="decimal"
calculate="if(../scale='C',
instance('thermostat')/ambient_temperature_c,
instance('thermostat')/ambient_temperature_c *
9 div 5 + 32"/>
<bind ref="instance('display')/target" type="decimal"/>
<bind ref="instance('thermostat')/target_temperature_c"
calculate="if(instance('display')/scale='C',
instance('display')/target,
(instance('display')/target - 32)* 5 div 9")/>
The controls in XForms specify what they do, not how they look
<select1 ref="instance('display')/scale" label="Scale">
<item label="°C" value="C"/>
<item label="°F" value="F"/>
</select1>
Although you could just input the target temperature:
<input ref="instance('display')/target" label="Target"/>
It is better to use the control for ranges, which allows a display of a rotary control for instance:
<range ref="instance('display')/target" label="Target"
step="0.5"/>
and include limits:
<range ref="instance('display')/target" label="Target"
step="0.5" start="0" end="30"/>
Of course, these limits depend on which scale is being used. Better still is put the limits in the instance, and link them to the scale used:
<instance id="display">
<data xmlns="">
<temperature/>
<target>20</target>
<scale>C</scale>
<start/>
<end/>
</data>
</instance>
<bind ref="instance('display')/start"
calculate="if(../scale='C', 0, 32)"/>
<bind ref="instance('display')/end"
calculate="if(../scale='C', 30, 85)"/>
and then on the control:
<range ref="instance('display')/target" label="Target"
step="0.5" start="{../start}" end="{../end}"/>
In the model you specify where to send the data, and what to do with the returned result:
<submission resource="http://thermostat.local/data"
method="put" replace="instance"/>
Normally you activate this with a button in the user interface:
<submit label="Submit"/>
However, in a direct-manipulation interface like a thermostat, you want the new values to be submitted without further user intervention.
For that, there is an XForms action that causes the data to be submitted:
<send/>
We just need to state under what circumstances it is to be activated.
In XForms, just as in HTML, you can listen for events, and then respond to them. In this case, we want to react to changes in the control:
<range ref="instance('display')/target" step="0.5" ...>
<action ev:event="xforms-value-changed">
<send/>
</action>
</range>
This says: when the xforms-value-changed event happens on the range control, submit the data.
With an interface to something that is continually updating, you need to poll it regularly for updates.
<model id="model">
...
<dispatch ev:event="xforms-ready"
name="my-timer" delay="20000" targetid="model"/>
<action ev:event="my-timer">
<send/>
<dispatch name="my-timer" delay="20000"
targetid="model"/>
</action>
</model>
<repeat ref="firewall/rules" label="Exceptions"> <output ref="./port" label="Port"/> <output ref="./url" label="URL" /> </repeat>
<instance id="label"
resource="http://example.com/labels-en.xml" />
Which looks like
<labels lang="en"> <submit>Submit</submit> <help>Help</help> <scale>Scale</scale> ... </labels>
Then
<select1 ref="instance('display')/scale"
label="{instance('label')/scale}"> ...
In fact the Nest produces its data as JSON. But we don't care!
There is no essential difference between:
{"temperature": {"scale": "C"; "value": 21}}
and
<temperature> <scale>C</scale> <value>21</value> </temperature>
XForms 2.0 accepts JSON and treats it as XML.
It is also possible to deal with text returned from a device.
Experience has shown that XForms reduces the time needed to produce an application by an order of magnitude.
For instance, one big example reduced the time from 5 years with 30 people to 1 year with 10 people: from 150 person-years to 10 person-years!
There are a number of implementations available, including client-side and server-side implementations.
XForms is part of Open Office/Libre Office