After reading the following quote from Tim Berners-Lee I have been reflecting on the appropriateness of my proposal of a HyperText Computer — a model computer built on top of HTTP:

From the fact that the thing referenced by the URI is in some sense repeatably the same suggests that in a large number of cases the result of de-referencing the URI will be exactly the same, especially during a short period of time. This leads to the possibility of caching information. It leads to the whole concept of the Web as an information space rather than a computing program. It is a very fundamental concept.

— Universal Resource Identifiers — Axioms of Web Architecture

Does the HTC undermine the idea of the web being an information space rather than a computer program?

The web’s information space is underpinned by an enormous amount of computing. Many, perhaps even most, URLs are dereferenced not to static information, but are generated on-the-fly by the execution of computer programs. Further, the conceptual simplicity of the web browser has been compromised by web documents carrying Javascript with them that is executed within the browser.

A foundational principle of the proposed HTC is that all computing resources are presented as the capability to fulfill HTTP requests. So long as the distinction between HTTP GET and POST are respected Berners-Lee’s observations about the information space will still apply. The proposed HTC also provides an alternative to browser hosted execution of code – this has the potential of reducing the amount of code embedded in webpages which would strengthen the role of HTML rather than reduces it.

My conclusion is that the HTC strengthens the ideal of the web “as an information space rather than a computer program”.

Tim Berners-Lee has written several articles about the axioms and design principles behind the web. I have been curious as to how many of the basic principles of the web are broken by the proposed HyperTExt Computer (HTC).

A key idea of the HyperText Computer (HTC) is that every operation is an HTTP request and all information is addressed by the HTC via URLs. Here is a summary of the princples and axioms with comments about the HTCs compliance:

Axioms from Universal Resource Identifiers — Axioms of Web Architecture:

Design Principles from Principles of Design:

How does an HTC reinforce the Principle of Least Power?

Burners-Lee says:

I chose HTML not to be a programming language because I wanted different programs to do different things with it [the HTML text]: present it differently, extract tables of contents, index it, and so on.

It is the simplicity of HTML as a declarative language that underlies its reuseability. XHTML+CSS make the text of webpages even more reusable by removing almost all of the rendering hints out of the text of the page. Javascript in today’s browsers allows them to take some processing load off the webserver and offer low latency processing and temporary storage. While the Javascript to be executed is sourced from the webserver, its programming model is discontinuous with that of the webserver. The webserver is accessed over the network, Javascript executes in a local sandbox.

The last 10 years has taught the web community a lot about how to securely deliver code to a user’s browser for local execution. The HTC is, in part, an attempt to fold what has been learnt back into the original HTTP protocol. The HTC model of handling client side processing has been discussed here. The HTC is proposed as a way of providing the client side processing without needing to resort to an “in-browser” processing environment. Using the HTC model, the browser could revert to being an pure interpreter of a declarative page description language. This could strengthen the value of the “Least Power” language HTML.

Additional Principles from Web Architecture from 50,000 feet:

anything, absolutely anything, “on the Web” should identified distinctly by an otherwise opaque string of characters (A URI and possibly a fragment identifier) is core to the universality

Comment: The HTC takes this principle to its logical conclusion.

The ideal goals, then, for an evolution of HTTP – would include:
…
# A schema system which allows any (Corba, DCom, RMI, etc) RPC interface to be defined, with an implied standard efficient format for RPC transmission;
# Extensions to the RPC state transition protocols to allow asynchrony needed for web applications (bidirectionality, streaming, asynchronous calls…);

Comment: Berners-Lee anticipates HTTP being used for computer to computer Remote Procedure Calls. The contribution of the HTC needs to be compared and contrasted with the technologies listed in this quote. It does not appear that the HTC idea of building a computer entirely on top of an end to end network protocol is in view here. In addition to the initiatives listed by Berner-Lee, the HTC needs, also, to be compared and contrasted with web services, mashups, Amazon’s S3, and middleware initiatives.

Conclusion
The proposed HTC does not seem to be in conflict with any of the principles and axioms described in these articles by Berners-Lee. The originality of this invention is an open question.

Client side scripting enables the local client computer to perform parts of the processing required by a web application. Javascript is a client-side part of the magic sauce that makes AJAX apps so fluid and useful. This works, of course, but why do we need separate client side and server side technologies? The HyperText Computer provides an alternative to client side scripting.

The HyperText Computer (HTC) is a computer built on the HyperText Transport Protocol (HTTP). In a HTC, every operation is implemented by a HTTP request and all information is accessed via document URLs. Because of this the processing of any program may be seamlessly moved from the remote server to be executed locally without employing a new language technology.

It could work like this: When a user asks for a URL to be displayed in their browser, if the local HTC has spare processing or storage capacity this may be indicated in the HTTP request. The remote server, after receiving the request has a choice of returning the document that is at that URL or returning a URL of the code that when executed will generate the document. This works because the code that the server would have run retrieves all the information it needs by retrieving other URLs — that could just as easily be retrieved by the local HTC. If a browser, having indicated that it has local processing capacity available, receives code instead of HTML in reply to a request , it does not execute the code, instead it initiates a request of its local HTC passing the URL of the code to be executed.

The required extensions to HTTP to enable this mechanism is an open area for research. One consideration would be a mechanism servers could indicate a lifetime of the code returned in response to a HTTP request.

The HTC’s uniform model relying exclusively on HTTP requests and URLs means that the locus of processing is seamlessly transferable from one computer to another.

A couple of days ago, John Milan in his “Changing Climates for Microsoft and Google, Desktops and Webs” post on Read Write Web, explored the balance of local verses remote processing and storage and the battle between Microsoft and Google. Earlier today my post was on just this topic: The HyperText Computer and Rich Internet Applications.

The HyperText Computer may provide an alternative to the need for special technologies created just for Rich Internet Applications.

The HyperText Computer (HTC) is a computer built on the HyperText Transport Protocol (HTTP). In a HTC, every operation is implemented by a HTTP request and all information is accessed via document URLs.

Rich Internet Applications (RIA) are programming environments that blend the capabilities of desktop and web applications, these offer advantages such as richer interface, smoother interaction, balance of processing load and network efficiency. At the present time, RIAs are being popularised around a variety of technologies – Flash, Flex, ActiveX, Java and others.

The amount of processing and storage done locally verses that which is done remotely is one of the key tradeoffs in designing computing solutions. Larry Ellison’s vision of a “Network Computer” (resurrected just this week) argues that the future is in doing almost no computing or storage locally. Full blown PCs running their own applications are the other extreme, with RIAs a middle ground with processing shared between the local computer and a remote server.

Today each of these scenarios employs different programming technologies and methodologies to deliver computing to end users. In the HTC model, local and remote computing resources are presented uniformly to programmers as a capacity to fulfill HTTP requests. This means that the HTC offers a model of computing that can support each of these scenarios using one programming model.

A minimal computer with just enough power to run a user agent (browser) would source all its processing and storage through HTTP requests of remote computers. If more processing power and or storage was available locally it would be available to fulfill processing and storage requests that must be done off-line or with lowest latency. Applications could, as well, be run completely locally, drawing only on the local computer’s capacity to service HTTP requests. In this way, the programming model of the HTC avoids the necessity to commit to a technology (like Flex) which forces you into one of these three models for running your application.

Instead of using special technologies to achieve a desired balance between local and remote processing – an HTC allows the right balance to be achieved based on factors like: the availability of local resources and the willingness of the owner of the programming code in question to allow it to be transferred to and executed by a local HTTP server.

The HyperText Computer (HTC) is proposed as a model computer. Built on the HyperText Transport Protocol (HTTP), the HTC is a general purpose computer. In its basic instruction set, every operator is implemented by a HTTP request and every operand is a URL referring to a document. The HTC is a foundational model for distributed computing.

Motivation for the HTC comes from observations that the browser may be considered a special purpose (as opposed to general purpose) model computer. Technologies like AJAX at the presentation level and iSCSI at the transport level are so undermining the Fallacies of Distributed Computing that inter and intra-computer communications not carried over IP are looking like special case optimizations. As noted by Cisco’s Giancarlo, IP networking is rivalling computer backplane speeds leading him to observe that “It’s time to move the backplane on to the network and redesign the computer”.

The HTC is a redesign of the computer. The transition from computers being connected by networks to the network as a computer has been anticipated for some time. The HTC is a model of a computer built from the ground up containing no implicit information about locality or technology.

Of course, implementation of this model will require optimisation of interconnections. A naive implementation of a HTC would have it spending 99.999% of its time in network routines fetching every operand and operator. Without affecting the programmer’s view of the HTC one may be built in silicon by hiding the optimised and messy implementation behind an onchip NAT. Programs written for the HTC will also run without change with its components distributed on 5 continents.

Computers of the future will contain just enough processing power to run a user agent. Any additional processing power or storage available locally will be available as an HTC with low latency. However, unplugging the local computing resources, does not impact the users or the programmers view in any way. In this case, other issues such as intellectual property will dominate decisions as to where and how processing is done.