davidpratten.com

J.E. Gordon’s book is a great read. Did you know that arches are so popular because they have to break in 4 places before they will fall down? Amazing factoids and insights for the lay person abound in this book. The technical details occasionally got a bit heavy.

The book comes to this wonderful conclusion:

Is it not fair to ask the technologist, not Only to provide artefacts that work, but also to provide beauty, even in the common street, and above all to provide fun? Otherwise technology will die of boredom. Let us have lots of ornament. … Since we have created a whole menagerie full of new artefacts, … , let us sit down and think what fun we can have in devising new kinds of decorations for them.

I did not expect to find an explanation of the success of Web 2.0 websites in a book on constructions. It was fun to realise that Web 2.0, like successful architecture owes much to skiamorphs, fakes and ornaments!

Thomas P. Hughes “Human-Build World - How to think about technology and culture” compares and contrasts current optimism about the Internet, gadgets and technology with human attitudes to earlier generations of technology. Technology has a much longer history than the popular mind may be aware! A great read for anyone responsible for implementing technology. The book shows that our current rush to technology is part of a picture that has been being drawn for a long time.

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”.