<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>David Pratten &#187; HyperText Computer</title>
	<atom:link href="http://www.davidpratten.com/tag/hypertext-computer/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.davidpratten.com</link>
	<description>Interests, Ideas and Observations</description>
	<lastBuildDate>Tue, 18 May 2010 00:49:55 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>Opera Unite and Tier Agnostic Computing</title>
		<link>http://www.davidpratten.com/2009/06/16/opera-unite-and-tier-agnostic-computing/</link>
		<comments>http://www.davidpratten.com/2009/06/16/opera-unite-and-tier-agnostic-computing/#comments</comments>
		<pubDate>Tue, 16 Jun 2009 15:31:42 +0000</pubDate>
		<dc:creator>david</dc:creator>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[Distributed]]></category>
		<category><![CDATA[HyperText Computer]]></category>
		<category><![CDATA[Opera Unite]]></category>
		<category><![CDATA[Request]]></category>
		<category><![CDATA[Teir Agnostic]]></category>

		<guid isPermaLink="false">http://www.davidpratten.com/2009/06/16/opera-unite-and-tier-agnostic-computing/</guid>
		<description><![CDATA[Opera has just released Opera Unite web server in the browser technology. Here is analysis by Mashable. Opera Unite is an enabling technology for tier agnostic Request Based Distributed Computing (RBDC). Key issues directly addressed by Opera Unite include: Drivers Build Distributed Applications Provide programmers with a unified programming model (i.e. not deal with a separate programming model on the client) Build Mult-tier applications Use existing technologies Enable applications to &#8216;run anywhere&#8217; Provide a Language agnostic mechanism Use a Client agnostic approach Conclusion Reading the Opera Unite announcement has confirmed that the building blocks of RDBC are coming into being.]]></description>
		<wfw:commentRss>http://www.davidpratten.com/2009/06/16/opera-unite-and-tier-agnostic-computing/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Internet All The Way Down</title>
		<link>http://www.davidpratten.com/2008/03/20/internet-all-the-way-down/</link>
		<comments>http://www.davidpratten.com/2008/03/20/internet-all-the-way-down/#comments</comments>
		<pubDate>Thu, 20 Mar 2008 09:40:58 +0000</pubDate>
		<dc:creator>david</dc:creator>
				<category><![CDATA[HyperText Computer]]></category>
		<category><![CDATA[RBDC]]></category>

		<guid isPermaLink="false">http://www.davidpratten.com/2008/03/20/internet-all-the-way-down/</guid>
		<description><![CDATA[&#8220;STEPS Toward The Reinvention of Programming&#8221;[linkmoved] has a great piece about the promise of a uniform model of computation based on arbitrary decomposition to the internet. On p32 they say: Part of the solution to “an Internet all the way down” has interesting conflicts with today’s hardware and we are curious to see just how far this can be taken without having to posit a different (but pretty minimal) set of machinery to help out. Basically, we would like to make a distributed object system that is (a) so protected that it can allow completely foreign objects to be brought in from elsewhere without causing harm, and (b) so efficient that a much higher level of abstract communication can be used between objects (perhaps an advanced form of “publish and subscribe” or “forward inferencing using knowledge patterns”). One of the central observations underlying RDBC (and Hypertext Computing) is just this idea of the Internet All the Way Down!]]></description>
		<wfw:commentRss>http://www.davidpratten.com/2008/03/20/internet-all-the-way-down/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Architecting Server/Client Convergence</title>
		<link>http://www.davidpratten.com/2008/02/10/architecting-serverclient-convergence/</link>
		<comments>http://www.davidpratten.com/2008/02/10/architecting-serverclient-convergence/#comments</comments>
		<pubDate>Sun, 10 Feb 2008 17:14:17 +0000</pubDate>
		<dc:creator>david</dc:creator>
				<category><![CDATA[HyperText Computer]]></category>

		<guid isPermaLink="false">http://www.davidpratten.com/2008/02/10/architecting-serverclient-convergence/</guid>
		<description><![CDATA[In this post I argue that the current convergence of Desktop and / Web Apps (RIAs) suggests a convergence of Server and Clients and that this opens up some interesting possibilities. I have been following an interesting series of posts by Arnon Rotem-Gal-Oz on the web/desktop convergence trend (all four posts are worth reading!). As well, in January and April, Arnon observes software converging towards: the ease of deployment of web applications, the richness and responsiveness of desktop apps, using a unified programming model for the whole app. Technologies competing for the privilege of delivering some or all of this trifecta include (but are not limited to) AJAX, Adobe Flex, Flash, Adobe Air, Microsoft Silverlight, JavaFX, Google Gears, Mozilla Prism, Aptana&#8217;s Jaxer and JNext. These technologies are being developed in the context of increasing awareness of two trends 1) the possibilities of &#8216;on-tap&#8217; cloud computing and simultaneously 2) the promise of 100&#8242;s of cores in our client computers. Here are some observations about the current web-app situation: Increasingly, the Virtual Machine environments on the server are being introduced down the tiers and ported to clients. (Silverlight&#8217;s CLR, and Java VM come to mind.) The use of Javascript in browsers has [...]]]></description>
		<wfw:commentRss>http://www.davidpratten.com/2008/02/10/architecting-serverclient-convergence/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Adaptive control of Request Based Distributed Computing</title>
		<link>http://www.davidpratten.com/2008/02/09/adaptive-control-of-request-based-distributed-computing/</link>
		<comments>http://www.davidpratten.com/2008/02/09/adaptive-control-of-request-based-distributed-computing/#comments</comments>
		<pubDate>Sat, 09 Feb 2008 11:33:01 +0000</pubDate>
		<dc:creator>david</dc:creator>
				<category><![CDATA[Adaptive]]></category>
		<category><![CDATA[autonomic]]></category>
		<category><![CDATA[HyperText Computer]]></category>
		<category><![CDATA[RBDC]]></category>

		<guid isPermaLink="false">http://www.davidpratten.com/2008/02/09/adaptive-control-of-request-based-distributed-computing/</guid>
		<description><![CDATA[The purpose of this post is to illustrate the possibility for autonomic computing inherent in Request Based Distributed Computing (RBDC). This is how I summarised RBDC in a recent post: Request Based Distributed Computing is a small extension of the http protocol and notion of server, proxy and client. Rich Internet Applications, SOA architected applications and SETI@home type distributed computing alike can utilise a common unified programming model. No longer will technology dictate the locus of code execution &#8211; instead issues like availability of computing power, intellectual property and security will dictate this at run time. This discussion focuses on the way that RBDC creates two ways to satisfy many http requests. The two ways are illustrated in the following two diagrams. These diagrams are similar to those in a earlier discussion. In the first scenario (DIAGRAM 1) we see a client requesting resource A and evaluating code locally to satisfy its own http request. DIAGRAM 1 In the second scenario (DIAGRAM 2) we see the same client. However in this case, when the client requests resource A, the client does not tell the server about it&#8217;s local computing capacity. In this case the relevant code is evaluated on the [...]]]></description>
		<wfw:commentRss>http://www.davidpratten.com/2008/02/09/adaptive-control-of-request-based-distributed-computing/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Tier-Agnostic Requests and Wadi</title>
		<link>http://www.davidpratten.com/2008/02/09/tier-agnostic-requests-and-wadi/</link>
		<comments>http://www.davidpratten.com/2008/02/09/tier-agnostic-requests-and-wadi/#comments</comments>
		<pubDate>Sat, 09 Feb 2008 06:59:33 +0000</pubDate>
		<dc:creator>david</dc:creator>
				<category><![CDATA[HyperText Computer]]></category>
		<category><![CDATA[RBDC]]></category>
		<category><![CDATA[requests]]></category>
		<category><![CDATA[tier agnostic]]></category>
		<category><![CDATA[wadi]]></category>

		<guid isPermaLink="false">http://www.davidpratten.com/2008/02/09/tier-agnostic-requests-and-wadi/</guid>
		<description><![CDATA[Tier-Agnostic requests are being used by the Wadi project in Java Server Farms. This Java-specific implementation lends support to the general applicability of Request Based Distributed Computing (RBDC) for client centric distributed computing. WADI is an acronym of &#8216;WADI Application Distribution Infrastructure&#8217;. WADI started life as a solution to the problems surrounding the distribution of state in clustered web tiers. It has evolved into a more generalised distributed state and service framework. The Wadi Docs describe an Invocation mechanism that shares features with RBDC. The Invocation Interface is a tier-agnostic encapsulation of a remote call. Here is a first-cut comparison: Similarities Both use the idea of Tier-Agnostic Requests They have similar session-state mechanisms. See here for one proposal about state within RBDC. Both delay location of computing decisions until run-time. Differences Wadi is targeted for use within a server farm, where as RBDC is proposed as starting in the client and works into the server farm with the same mechanism. Wadi maintains centralised knowledge of the location of active Java objects whereas RBDC works as an extension of http&#8217;s native request by request invocation pattern. Wadi is programmed specifically for Java, RBDC is proposed as a generic mechansim. Wadi is [...]]]></description>
		<wfw:commentRss>http://www.davidpratten.com/2008/02/09/tier-agnostic-requests-and-wadi/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Tier-agnostic Requests and Microsoft Volta</title>
		<link>http://www.davidpratten.com/2008/02/08/tier-agnostic-requests-and-microsoft-volta/</link>
		<comments>http://www.davidpratten.com/2008/02/08/tier-agnostic-requests-and-microsoft-volta/#comments</comments>
		<pubDate>Fri, 08 Feb 2008 07:56:08 +0000</pubDate>
		<dc:creator>david</dc:creator>
				<category><![CDATA[Distributed]]></category>
		<category><![CDATA[HyperText Computer]]></category>
		<category><![CDATA[Request]]></category>
		<category><![CDATA[Teir Agnostic]]></category>
		<category><![CDATA[Volta]]></category>

		<guid isPermaLink="false">http://www.davidpratten.com/2008/02/08/tier-agnostic-requests-and-microsoft-volta/</guid>
		<description><![CDATA[Recently my attention has been directed to Microsoft&#8217;s Volta split-tier technology. Volta is addressing the same set of issues as Request Based Distributed Computing (RBDC). Key issues directly addressed by both Volta and RBDC include: Drivers Build Distributed Applications Provide programmers with a unified programming model (i.e. not deal with a separate programming model on the client) Build Mult-tier applications Use existing technologies Delay architectural decisions about the splitting of workload between client and server Enable applications to &#8216;run anywhere&#8217; Provide a Language agnostic mechanism Use a Client agnostic approach Not withstanding that Volta deserves credit for being a real-live (beta) product while RBDC is still in gestation as an architectural idea, I want to argue that RBDC which is based on tier agnostic requests, is an architecturally cleaner solution to the problems of client centred distributed computing. The three areas that I would like to highlight are simplicity, generality and run-time architectural decisions. Simplicity If you look at these illustrations of RBDC the tier agnosticism of requests leads to an extremely simple mechanism for distributed computing with equivalent expressive power to Volta. Generality Volta is specifically targeting the .Net platform whereas the RBDC mechanism is not just language agnostic, [...]]]></description>
		<wfw:commentRss>http://www.davidpratten.com/2008/02/08/tier-agnostic-requests-and-microsoft-volta/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>RBDC Illustrated</title>
		<link>http://www.davidpratten.com/2008/02/06/rbdc-illustrated/</link>
		<comments>http://www.davidpratten.com/2008/02/06/rbdc-illustrated/#comments</comments>
		<pubDate>Wed, 06 Feb 2008 17:25:32 +0000</pubDate>
		<dc:creator>david</dc:creator>
				<category><![CDATA[Browser]]></category>
		<category><![CDATA[Distributed]]></category>
		<category><![CDATA[HyperText Computer]]></category>
		<category><![CDATA[RBDC]]></category>
		<category><![CDATA[VM]]></category>

		<guid isPermaLink="false">http://www.davidpratten.com/2008/02/06/rbdc-illustrated/</guid>
		<description><![CDATA[The purpose of this post is to illustrate the behaviour of Request Based Distributed Computing (RBDC). This is how I summarised RBDC in a recent post: Request Based Distributed Computing is a small extension of the http protocol and notion of server, proxy and client. Rich Internet Applications, SOA architected applications and SETI@home type distributed computing alike can utilise a common unified programming model. No longer will technology dictate the locus of code execution &#8211; instead issues like availability of computing power, intellectual property and security will dictate this at run time. Using the mechanisms explained below the need for separate programming models on server and client is removed. RDBC is language neutral, but for illustration purposes, in the following example lets assume that the server code is written in PHP. Distributed computing may be facilitated by mobile code moving from the server to a browser that is equipped with one or more RBDC compatible Virtual Machines. In Diagram 1 the example Virtual Machines (VMs) are in circles labeled &#8220;hXXX&#8221; one for each of 3 major web environments. The VM&#8217;s in server and client are identical. Notice that the server does not return the requested &#8220;Resource A&#8221;, but rather the [...]]]></description>
		<wfw:commentRss>http://www.davidpratten.com/2008/02/06/rbdc-illustrated/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>RBDC, Continuation Passing Style, Closures, Lazy Evaluation and Mobile Applets</title>
		<link>http://www.davidpratten.com/2008/02/03/rbdc-continuation-passing-style-closures-lazy-evaluation-and-mobile-applets/</link>
		<comments>http://www.davidpratten.com/2008/02/03/rbdc-continuation-passing-style-closures-lazy-evaluation-and-mobile-applets/#comments</comments>
		<pubDate>Sun, 03 Feb 2008 11:15:08 +0000</pubDate>
		<dc:creator>david</dc:creator>
				<category><![CDATA[HyperText Computer]]></category>

		<guid isPermaLink="false">http://www.davidpratten.com/2008/02/03/rbdc-continuation-passing-style-closures-lazy-evaluation-and-mobile-applets/</guid>
		<description><![CDATA[It has been recently pointed out to me that the mechanisms underlying Request Based Distributed Computing &#8211; RDBC (see primer) are related to Continuation Passing Style CPS, Closures, Lazy Evaluation and Mobile Applets. This is a good insight. Lets have a look at it. The CPS pattern is where the caller passes the callee code which the callee runs when when the callee is done with his unit of work. Return never passes to the caller, but rather to the third party designated by the caller. CPS is a widely used programming style that addresses different kinds of issues to RDBC. CPS does not address the question of the locus of code evaluation whereas with RBDC there is an explicit mechanism that controls whether evaluation proceeds in the callee or the caller. Also, in CPS the callee operates with implicit trust that the caller will pass a sensible continuation, in RBDC the callee (server) does not trust the caller (client) and never receives code from the caller. Closures is a mechanism that associates a function with state that lasts between invocations. Closures are often used in languages (like lua) where functions are themselves first-class objects. Closures and RBDC share at [...]]]></description>
		<wfw:commentRss>http://www.davidpratten.com/2008/02/03/rbdc-continuation-passing-style-closures-lazy-evaluation-and-mobile-applets/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Distributed Computing with the Browser</title>
		<link>http://www.davidpratten.com/2008/01/16/distributed-computing-with-the-browser/</link>
		<comments>http://www.davidpratten.com/2008/01/16/distributed-computing-with-the-browser/#comments</comments>
		<pubDate>Wed, 16 Jan 2008 09:59:14 +0000</pubDate>
		<dc:creator>david</dc:creator>
				<category><![CDATA[Posts]]></category>
		<category><![CDATA[HyperText Computer]]></category>

		<guid isPermaLink="false">http://www.davidpratten.com/2008/01/16/distributed-computing-with-the-browser/</guid>
		<description><![CDATA[Recently, Subbu posted an interesting discussion of an xml analysis and presentation application &#8211; you can read it here: Distributed Computing with the Browser. This design scenario is a good illustration of the limitations of our current situation with programming . Our current situation is that while the WWW allows a programmer to ignore the network path to an information resource, as programmers, we can&#8217;t ignore where computing will be done. The programmer’s choice of technology (framework, language etc etc) carries with it the implicit choice about the location of computation (server or client). An assumption behind Subbu&#8217;s post is that we need to decide the location of processing during the design phase. The purpose of this post is explore how the application could be built using Request Based Distributed Computing RBDC (see backgrounder). With the application recast as a RBDC application, the location-of-processing decisions can be made at runtime based on the availability of computing power and storage, intellectual property, and security issues. The XML analysis and presentation application using RBDC (This description presumes that you have read the RBDC backgrounder.) The key distributed process in this application is the initial analysis of the source XML text, and the [...]]]></description>
		<wfw:commentRss>http://www.davidpratten.com/2008/01/16/distributed-computing-with-the-browser/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Code Mobility and Session State</title>
		<link>http://www.davidpratten.com/2008/01/16/code-mobility-and-session-state/</link>
		<comments>http://www.davidpratten.com/2008/01/16/code-mobility-and-session-state/#comments</comments>
		<pubDate>Wed, 16 Jan 2008 09:52:01 +0000</pubDate>
		<dc:creator>david</dc:creator>
				<category><![CDATA[HyperText Computer]]></category>

		<guid isPermaLink="false">http://www.davidpratten.com/2008/01/16/code-mobility-and-session-state/</guid>
		<description><![CDATA[Code mobility as provided for by Request Based Distributed Computing RBDC (see backgrounder) is key for delivering On-Demand computing, Distributed Computing (e.g. SETI@home) and Rich Internet Applications. RBDC enables the mobility of code that gets its input from http sources (url, request body, cookie, and passwordless GETs). This post looks into whether session state can be made mobile as well. How can code that relies on session state be made mobile? In a typical scenario, http servers associate session state with client request streams through the use of a server-unique session-id that is preserved between accesses via a cookie. An example of this is PHP&#8217;s handling of sessions. Under this scheme the server held session state prevents the code being mobile. The code is not mobile because the session state is only available in the server that generated the client&#8217;s requested resource. Using RBDC, code that relies on session state can be made securely mobile. Here is one way. [[Since writing this post, I have realised that the mechanism described here is the same mechanism that makes Google Reader Public Pages both globally available and private.]] Firstly, the server stores the session state using a globally-unique-id (GUID) insead of server-unique-id [...]]]></description>
		<wfw:commentRss>http://www.davidpratten.com/2008/01/16/code-mobility-and-session-state/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
