SETI@home is a computing project that analyzes radio telescope data using the spare computing power available in internet connected computers. Users who wish to offer their computers’ processor and storage to the project, download and install BOINC – the Berkeley Open Infrastructure for Network Computing. BOINC accepts units of computing work from the seti@home server, does the work on your computer and then returns the results. BOINC also makes sure that the user’s other work is not interfered with by the seti@home work. The paper “Designing a Runtime System for Volunteer Computing (2006)” is a very readable description of how BOINC works.

BOINC shares many similarities with the proposed HyperText Computer (HTC). Lets look at how an HTC could be used to serve a project like seti@home.

HTC is, in part, an attempt to eliminate the effect of programmers implicitly making choices about where processing will be done through their choice of technology. Two core concepts of the HTC are that one, all computing resources are presented as the ability to complete HTTP requests, and two, that HTC programs reference all input information as URLs. Thirdly, the HTC depends on an extended HTTP which includes an offer of assistance along with the request for the information at a URL. The HTTP request becomes “please give me the information located in information space at this URL, and by the way, I have processing and storage available in my HTC and I am happy to help with the processing involved.” Webservers may return the HTML of a page, or code that calculates it. This mechanism provides an alternative to in-browser Javascript. These ideas are discussed here.

These mechanisms may also provide a generic alternative to special software like BOINC. Here is how it may work. If the computing resources of my desktop computer are managed by an HTC, and the seti@home project was also hosted on an HTC then from a user agent (browser), I could visit the seti@home website and request a “participate in seti@home project page”. This page would return their analysis code to my HTC which would begin executing the code, pulling radio telescope data from the seti@home server as needed using HTTP GET and HTTP POSTing the results back to the seti@home server when complete.

To accommodate the seti@home project, and other similar projects, an HTC on an end-user’s computer would need to adjust processing priorities based on the busyness of the computer and support long running threads.

Today, programmers who wish to use end-user computers’ spare cycles for their projects must use the special programming model offered by tools like BOINC to accomplish this. The proposed HTC, provides an alternative to this, where the programming model is the same wherever the processing takes place. The unification of the programming model makes life easy for programmers, and also for those responsible for corporate IT infrastructure. For example, in a corporate environment, a proxy server could trap the returned code and execute it on behalf of a user’s browser without the programming model or user being affected!

As part of .NET 3.0 the Windows Communication Foundation (WCF) is a unified programming model from Microsoft that delivers many of the benefits motivating the proposed HyperText Computer. Some of the key benefits of the WCF include: Replacing 7-8 different programming models with a single one, the programmer may interact with local and remote objects using the same language constructs, and WCF is designed to be flexible – it is not confined to using only HTTP as its network protocol. WCF is also designed to connect to other web services using the WS-* standards.

However, in my reading, the features of WCF differ in a few key ways to the proposed HTC. While the programming model of WCF replaces many other models from Microsoft and therefore may be described as “unified”, the WCF “plumbing” is quite visible. Programmers still have to choose to employ WCF technology. And through their choice of technology to influence the locus of execution. The vision of the HTC is that every resource is accessed using a network protocol and that therefore the programming model is a unity. This is discussed here.

Also, the possibility of extending the unification of the programming model to the user agent (browser) level does not seem to be in view for the WCF. The present situation (e.g. AJAX) where the server operates on one model and the client browser on a separate one forces programmers through their technology decisions to choose the location of processing and storage. As discussed here the proposed HTC suggests an alternative to browser hosted languages and a mechanism for location-of-processing decisions to be made at run time. The HTC, related to this, offers a mechanism for automatic code mobility which does not seem to be addressed by WCF.

These comments not withstanding, the WCF is a major achievement and step towards a future where programmers truly do have a single programming model. And … it is also an implemented reality!

What has the web done for information? In short, the web has made the network invisible when retrieving information. The distance traveled and the technology employed to deliver a request from a browser and the response returned makes no difference to the user’s perspective. That is part of the magic of the web. The web has been designed so that caching can be automated. Information may be transparently moved in response to network conditions and local policy so that requests are satisfied in a way that is optimal for the owner of connected computing systems.

In contrast the situation for programmers is that the network is still very visible. Most computing environments still force programmers to choose in advance where processing is done. Often this choice is implicit in the choice of technology employed. PHP means processing done on the server. Javascript means processing done on the user’s computer. Most computing environments use widely different paradigms for accessing local resources vs remote resources. The computer carries within it implicit information about “here” and “out there on the net”.

The visibility of the network in the programming model means that programmers have to make explicit decisions about “here” and “there”. Just as this distinction has been erased for information retrieval, it is time to erase this distinction from our programming models. One way of achieving this is to explicitly build a model computer on top of HTTP. This is the approach taken by the proposed HyperText Computer (HTC). The HTC accesses all resources across the network. This uniformity in programming model allows the decision about where to execute the HTC’s code to be taken at runtime, similar to the way that caching makes runtime decisions about where to locate information. Depending on factors such as the availability of a local HTC, and the willingness of the owner of the code to allow it to be transported to other HTCs, computing could be done remotely or locally.

With the widely varying amounts of processing and storage available on a rapidly increasing array of devices, is it time to offer to programming the benefits that the web already offers for information retrieval, that is, make the network invisible?

This morning I found a recent report by Darryl K. Taft quoting Stefan Schoenauer of IBM titled “Future Net: Expanding the Web from Pages to Data Sources“. It appears that IBM’s Infinity middleware project may be a proto-HyperText Computer. While the details are sketchy, here is what we know…

The HTC is a model computer that processes information by making HTTP requests and references information only through URLs. In an HTC all computing power is presented as the ability to complete HTTP requests.

What is IBM’s Infinity project?

What prompted the Infinity project was a great big “what if,” Schoenauer said: What if all the information stored in devices like cell phones, PDAs, RFID (radio-frequency identification) chips and USB sticks could be accessed much the way Web sites are today, or even more easily

IBM’s [Infinity] prototype is notable because as yet there is no standard way to share data between diverse mobile devices directly in ad hoc networks. And because the variety of mobile operating systems offers so many different programming environments and interfaces, applications have to be custom-developed for each platform. The vast range of data types, database software and connection hardware involved make it difficult to achieve broad-spectrum mobile device integration. Infinity technology will improve cross-platform integration and communication for mobile applications, and will enable application developers to more easily develop applications for a variety of mobile devices, IBM said.

The goal is universal access to heterogeneous computing resources with a single programming model. This is. of course, very similar to the objective of the HTC.

The article is sketchy on the implementation details of the Infinity Project however, what is stated sounds as if the project is a step towards the creation of an HTC.

“The middleware itself looks very much like a Web server on the Internet. The applications are HTML pages with some JavaScript, and they communicate via HTTP.” In addition, the platform uses XML as a data exchange format, he said.

Each of the devices in question definitely has its own user agent (browser, interface). It also has additional computing capabilities that could be made available to others. It appears that Infinity presents the computing resources (processing and information) of all these devices on the net as the ability to fulfill HTTP requests. If so, that is a hallmark of the HTC. The article does not discuss the possibilities of code mobility offered by the HTC and still presumes the necessity of Javascript to which the HTC offers an alternative, but it appears that the Infinity project may be offering us a proto-HTC!

We live in interesting days.

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.