[third draft, thanks for your patience]
What's Wrong With HTTP?
=======================
In this essay, the first of a pair on browser apps, I explore how
they are better than traditional desktop apps in some ways, but
worse in others. Some of the disadvantages of browser apps are
deeply rooted in the use of HTTP URLs for naming. In the second
essay, I will present a design sketch for a new platform, a
replacement for HTTP combining both styles' advantages.
Right now, we're seeing a massive shift to browser apps, largely
server-side browser apps. As I warned in "People, places, things,
and ideas," [18] this move to server-side browser apps imperils
our software freedom; I outlined how to solve this problem in "The
equivalent of free software for online services." [19] This pair
of essays represents more detail on this problem and proposed
solution.
What's the Big Deal About Browser Apps?
---------------------------------------
By "browser app", I mean a computer program whose user interface
is a web browser --- for example, Hotmail, PBWiki, Slashdot,
Flickr, del.icio.us, Google Search, Google Maps, Sproutliner [45],
Babelfish, LiveJournal, NumSum, and the Trimpath Spreadsheet
embedded in NumSum. I'm not including programs like Macromedia
Flash Player or Windows Media Player, which are traditional GUI
applications that merely display their GUIs inside a web browser.
There are browser apps that run entirely on the server side,
browser apps that run entirely on the client side, and browser
apps that have parts on both sides; most of this essay discusses
all three without differentiation.
Kevin Barnes [16] and Yaron Goland [17] have written a bit about
why so many new computer programs are written as browser apps,
even browser apps with difficult-to-write client-side parts.
Yaron explains:
I think one of the key aspects of the browser's success is
that it is, in essence, a pain free application installation,
execution and de-installation environment.
You can 'install' software just by navigating to it, no
install dialogs to worry about, no disk space issues to check,
to permissions to fret over, no conflicts to deal with, and
when you are done with the "software" (a.k.a. web page) the
software just vanishes (well mostly...).
All of which leads me to point out that when we look for the
new browser to replace the AJAX [49] browser we must make sure
it keeps the same 'pain free' execution environment
characteristics of the browser.
Philip Greenspun [20] and Paul Graham [21] have also written quite a
bit on the advantages of browser apps, although they mostly focused on
pure server-side browser apps.
I find myself writing more and more of my kragen-hacks posts as
client-side browser apps in DHTML so people can run them more easily.
However, browser apps have some serious drawbacks.
How Browser Apps Are Different
------------------------------
Browser apps are different from traditional desktop apps in
several ways, listed briefly here and then in more detail. They
do each of the following:
* Install painlessly.
* Run in a sandbox.
* Are location-transparent.
* Are part of the web.
* Support collaboration.
* Don't integrate with the desktop.
* Don't work offline.
* Upgrade instantly.
* Support "view source".
* Run slowly.
* Aren't trustworthy.
* Have a higher-level GUI toolkit.
* Have a quicker edit-run cycle.
In more detail:
* Install painlessly
As Yaron pointed out, you don't have to "install" browser apps;
your computer still downloads and runs them, but you don't have to
engage in a long dialog with it just to get them running.
* Run in a sandbox
Insecure or malicious browser apps can't steal or delete your
files, because they only have access to the files you explicitly
give them, and they can't spread viruses to other browser apps,
because they don't have access to them.
* Are location-transparent
You can use any browser app from any computer, and access all of
its data.
* Are part of the web
You can link from any web page to your photos on Flickr or to
search results on Google; Google can index your LiveJournal blog
if you let it; you can print a Slashdot conversation, or
text-search your del.icio.us bookmarks from the browser. In
general, data in a browser app is usually a first-class citizen of
the web.
All of these virtues come from two aspects of the architecture of
the web: REST [22] and the Rule of Least Power [23]; browser apps
not designed with them in mind do not integrate well with the rest
of the web.
* Support collaboration
Partly because they're location-transparent and web-integrated,
browser apps support social interaction more easily than desktop
apps.
* Don't integrate with the desktop
Browser apps are clumsy at cooperating with your desktop ---
exchanging data and so forth --- and sometimes this makes them
clumsy to use. On the other hand, you can pretty much use them
regardless of what operating system or installed DLLs you have ---
incompatibilities are rare and mostly easy to fix.
* Don't work offline
Most browser apps run partly on the server side, and at present,
there's no good way for them to run offline.
* Upgrade instantly
Whether you want to or not, as soon as you hit reload, you're
running the latest version installed on the web server. This is
often a great benefit, but it induces a single point of failure
--- the server operator can install a new version that violates
your privacy, and you are defenseless.
* Support "view source"
While you can't view the source code that runs on the server side,
you can see all the UI elements. But with Ajax [49] and
Greasemonkey [40], it's easier and easier to view and customize
the app logic.
* Run slowly
While the part that runs on the server can be fast (although you
may have to share that server with hundreds of thousands of other
users), the communication with the server rarely is, and any
client-side part runs in a slow JavaScript interpreter. (The
JavaScript interpreter may speed up quite a bit soon with the
Tamarin project [31].)
* Aren't trustworthy
Today, browser apps always have a single point of failure --- the
owner of the server can turn it off, lock you out, or steal all
your private data. Desktop apps don't have this problem, as long
as you control your own computer. This is induced by the
particular approaches taken to the instant upgrade and
location-transparency problems.
* Have a higher-level GUI toolkit
Browser apps use the HTML DOM for their GUI toolkit. HTML is easy
to style with CSS; it's easy to put images into; it pervasively
supports Unicode; and the CSS box model layout system is much more
flexible than the model in any of the standard GUI toolkits. On
the other hand, it's often very slow.
* Have a quicker edit-run cycle
Unless you're the kind of person who writes their browser apps in
Java, it's very quick to see the results of your changes, without
losing any of your data; this speeds development.
The Postweb Browser Debate
--------------------------
There's been some discussion [50] [51] about how to remedy the
shortcomings of the browser as an application platform; this essay
was inspired by a discussion thread on ask.slashdot.org this month
[0] about the subject. In the original post, cyclomedia [1]
wonders:
"I've been thinking about this for a while now, and a recent
article posturing about Web 3.0 [2] brought forward some other
suggestions which basically boiled down to 'what should be
next.' Everyone here knows that HTML, Javascript and
HTTPRequest are not the tools for building feature-rich
interactive networked applications, but that doesn't stop
Google, Microsoft and others from trying their best to use
them to build office suites and the like. As one project puts
it: 'we need to replace the Document Browser with an
Application Browser.' So, let's get the ball rolling with my
question: What type of platform would you like to see
delivering the 'true' Web 2.0 in the not too distant future?"
The earlier-cited essays by Kevin Barnes [16] and Yaron Goland
[17] also touch on this question.
Although Slashdot's design rewards brevity and speed of response
over depth of thought, there were still some interesting comments
in the ask.slashdot thread; the main points as I understood them
follow:
* Java applets and Flash are intended as platforms for
zero-install feature-rich interactive networked GUI
applications. [3] [4] [10] [12]
* XUL [36] is a platform for such things too. [14]
* Such a platform needs sandboxing --- support for safely running
untrusted code. [5] [9] [11]
* Such a platform needs to store local state, like cookies, but
usable for more things --- for example, in files. [5] [11]
* It's better for users if code runs on the server, not on their
computer. [10] [15]
* Documents are better than applications, because they give more
control to the user. [9] [10]
* Documents are better represented in HTML than as programs. [6]
[8] [9] [[maybe "HTML is better than
* JavaScript is a terrible programming language. [6] [17] [37]
[38] [39]
* There's nothing wrong with the traditional desktop-app approach,
and AJAX and JavaScript and DHTML are just dumb ideas. [7] [8]
[13] [14]
* DHTML is too slow and memory-intensive. [8] [10]
* Yes, we need an "application browser" platform that's designed
for applications rather than documents, but has the advantages
of a web browser. [10] [11]
* What's wrong with the Web is mostly that it doesn't work
reliably, not that it's insufficiently feature-rich. [15]
I disagree with most of these points.
Responses to points in the Slashdot thread
------------------------------------------
* Java applets and Flash are intended as platforms for
zero-install feature-rich interactive networked GUI
applications. [3] [4] [10] [12]
That's true, but they lack several of the advantages of normal
browser apps. They don't integrate well into the web, so you
can't print them, text-search them, index their data with a search
engine, and so on. Things HTML makes easy, like scrollable
paragraphs of rich text wrapped to your screen width, become
difficult to write and difficult to use. You can't "view source"
on them or use Greasemonkey [40] to change how they work. They
still aren't desktop-integrated, but they suffer from the
compatibility problems DHTML mostly avoids.
However, they are faster, and they still install painlessly,
support collaboration easily, upgrade instantly, and you still
can't use them reliably offline.
* XUL [36] is a platform for such things too. [14]
It looks like you can run XUL as if it were a web page or as if it
were a desktop app, with mostly the advantages and disadvantages
of whichever mode you choose --- except that a JavaScript+XUL
desktop app will be more view-source-able than a desktop app
written in C++, and still painfully slow.
So I don't think XUL is very interesting. It's nice that it has
elements such as <treecontrol>, <tabbox>, and <radiogroup>, but
I don't think fancy widgets are a major advantage desktop apps
currently have over browser apps.
* Such a platform needs sandboxing --- support for safely running
untrusted code. [5] [9] [11]
You wouldn't really want painless installs and
location-transparency without sandboxing --- that would mean your
computer automatically installed programs with complete control
over your computer, without you even being awware of it. That's
why you don't use Internet Explorer, or you turn off ActiveX,
right?
So I agree; sandboxing is crucial.
* Such a platform needs to store local state, like cookies, but
usable for more things --- for example, in files. [5] [11]
Browser apps currently achieve location-transparency and web
integration by storing all your important information on servers
on the internet, addressable by URLs. This is one major reason
they aren't trustworthy --- whoever runs the server can delete
your information.
However, if you implement local state the way desktop applications
do --- as the WHATWG proposal for client-local storage does ---
you lose location-transparency and web integration, and you impede
collaboration.
In the next essay, I will explain a different way to make
browser applications location-transparent, without giving up
desktop-app-like trustworthiness.
* It's better for users if code runs on the server, not on their
computer. [10] [15]
I think it's better for users if code runs (sandboxed) on their
computer, because then they can see the code and change what it
does. That's why Google Maps had all kind of mashups coming out
within two or three months after it was announced, while MapQuest
had none even after years --- because the Google code was running
where people could "view source" and modify it: in their browsers,
not on Google's servers. [52]
* Documents are better than applications, because they give more
control to the user. [9] [10]
I agree with this --- you can index, print, search, and otherwise
analyze documents, things you cannot do in general with computer
programs that produce documents. This is an example of the Rule
of Least Power [23], one of the fundamental principles of the
web's design.
However, it's not really relevant to the question. Clearly we
should represent salmon recipes as HTML files rather than Java
applets; but how should we represent Flickr? We can't replace
Flickr with a mere static document. Maybe we could replace it
with a desktop app.
There's still the question of how much of people's data is
represented as documents they have access to, and how much is
locked away inside programs. Ajax tends to encourage servers to
make data available in a more document-like form --- rather than
running code on the server, outside of my control, to turn the
data something I can understand but my computer perhaps cannot,
the server sends the data in a document down to the Ajax code
running on my browser.
We still need better tools for making access to that data
practical for the majority of people, though.
* Documents are better represented in HTML than as programs. [6]
[8] [9]
This is a special case of the preceding point, and of course it is
correct, but it is still not relevant to the design of a platform
for non-document-like browser apps. XUL (and, perhaps, Visual
Basic) demonstrates that program user interfaces are mostly better
represented in simple static languages than in programming
languages, too.
* JavaScript is a terrible programming language. [6] [17] [37]
[38] [39]
I hear this a lot, but I don't agree. JavaScript is worse than
Perl or Python, but it's much better than C, C++, PHP, Java,
PostScript, or bash --- for most things.
Yaron complains [17]:
From its lack of modularity to its lack of typing to its
single threaded nature, to its dirt slow processing speed, to
its lack of a decent transient local storage model to its
inability to act as a true server, writing real code in
Javascript really and truly does suck. I realize some of these
complaints are more about the browser environment then
Javascript but separating the two is nearly impossible so I'll
pile them together.
Only three of these are complaints with JavaScript itself; I'll
address Yaron's complaints point by point.
I assume by "modularity" he means "a module system", and Dojo [24]
and JSAN [25] have added module systems more or less similar to
what you'd expect in modern languages like Python, Perl, or OCaml.
Presumably something like these systems will become standardized
soon.
JavaScript is dynamically typed, which is what Yaron means by
"lack of typing", and this has advantages and disadvantages. A
lot of people choose dynamically-typed languages (like Lisp, Perl,
and Python) on purpose, because they have some advantages for
readability and level of abstraction. [53] [54] [55] [56] [57]
[58]
Single-threaded programming can be easier and less bug-prone than
multithreaded programming [26] [27] [30], but only if you have the
right tools, like Twisted Python [28]. MochiKit [29] provides
facilities like these for JavaScript, and those facilities are
being incorporated into Dojo as well.
JavaScript-the-language could support multithreaded programming to
the same degree that C++ or Python does, of course, but that
doesn't make it a good idea.
The Tamarin project [31] should bring JavaScript's performance to
equal or better that of Perl and Python, which would be a major
improvement. It still probably won't make Yaron happy, since it
will still be one or two orders of magnitude slower than Java and
C#, but the things people will complain are too slow will be
things they don't even try now.
So of Yaron's three complaints about JavaScript-the-language, he
is simply wrong about two of them --- they are advantages of
JavaScript, not disadvantages --- and the third should improve
dramatically soon.
With regard to the other problems:
Yaron is acutely aware of the importance of location-transparency,
which is why he says "*transient* local storage model". I agree
with this complaint, but obviously it's a problem with the browser
environment, not JavaScript the language. Brad Neuberg's
dojo.storage [32] uses Flash to get around the problem, and the
entire section 5.3 [33] of the new HTML 5 or "Web Applications
1.0" spec [34] is devoted to solving this problem in the browser;
this facility as described in the HTML5 spec is shipping in
Firefox 2.0.
The "inability to act as a true server" is also just an
environmental problem. I think it's a helpful inability for
sandboxing, but it's not just untrusted JavaScript apps that can't
support incoming connections from the outside world --- neither
can the browser as a whole, so any information you store locally
is not available to the rest of the world (defeating
location-transparency). So I agree with this complaint as well.
Most of the other complaints I've heard about JavaScript are
either relatively inconsequential annoyances, or duplications of
the above [37] [38] [39].
* There's nothing wrong with the traditional desktop-app approach,
and AJAX and JavaScript and DHTML are just dumb ideas. [7] [8]
[13] [14]
I hope I haven't oversimplified the argument in the Slashdot
comments I cited; I think I have already sufficiently rebutted
this argument above.
* DHTML is too slow and memory-intensive. [8] [10]
This is true, and it's also true of XUL. Tamarin [31] will
probably help some with this. I don't know how to solve it in
general.
* Yes, we need an "application browser" platform that's designed
for applications rather than documents, but has the advantages
of a web browser. [10] [11]
That's my point of view. The next essay is about what it should
look like.
* What's wrong with the Web is mostly that it doesn't work
reliably, not that it's insufficiently feature-rich. [15]
Also, it's slow. The solution I will propose in the next essay
focuses primarily on removing reliability problems rather than
adding features.
Conclusion
----------
Today there are many compelling advantages to writing new programs
as browser apps, but the browser has some disadvantages as an
application platform as well.
In this essay, I have rejected many solutions proposed by Slashdot
posters. In the next essay, which I plan to publish Thursday, I
will present a design sketch for a browser platform that
eliminates the browser-app disadvantages I've identified here, by
means of a peer-to-peer document namespace, supporting browser
apps as rich as those we have today, but without the problems of
security and trustworthiness that plague current browser apps.
Thanks
------
Danny O'Brien, Lawton Chan, Alex Russell, Donovan Preston, David
Braginsky, Ben Sittler, and Eric Tiedemann have helped with this
essay; I greatly appreciate their help and their insights. But
it's not their fault.
Footnotes
---------
(a few of these pertain to the next part of the essay)
[0] "How Would You Usurp the Web Browser?", ask.Slashdot article,
2006-11-21
> http://ask.slashdot.org/article.pl?sid=06/11/21/0433212
[1] "cyclomedia"
> http://www.cyclomedia.co.uk/
[2] "Can the Web Survive v3.0", Slashdot article, 2006-11-19
> http://slashdot.org/article.pl?sid=06/11/19/1516236&tid=95
[3] Comment from "Z0mb1eman" (http://www.bloored.com/)
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16925626
[4] Comment from "suv4x4"
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16927666
[5] Comment from "plopez"
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16925652
[6] Comment from "illuminatedwax"
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16925814
[7] Comment from "SuperKendall"
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16925854
[8] Comment from "jd"
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16925856
[9] Comment from "Animats" (http://www.animats.com/)
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16926148
[10] Comment from "wikinerd" (http://www.wikinerds.org/)
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16926626
[11] Comment from "Pfhorrest"
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16926220
[12] Comment from "nickos"
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16925676
[13] Comment from "Squid" (http://flyingmice.com/squid/)
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16926372
[14] Comment by "scdeimos"
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16926372
[15] Comment from "dpbsmith" (htttp://www.dpbsmith.com/)
> http://ask.slashdot.org/comments.pl?sid=207664&cid=16928458
[16] "The next software revolution wears black leather", by Kevin
Barnes, 2005-11-09
> http://codecraft.info/index.php/archives/41/
[17] "AJAX is great, except for the J and the X", by Yaron Goland,
2006-12-19
> http://www.goland.org/beyondthebrowser/
[18] "People, places, things, and ideas," by Kragen Sitaker,
originally posted to kragen-tol on 1999-01-06
> http://lists.canonical.org/pipermail/kragen-tol/1999-January/000322.html
Also available on the GNU "Philosophy" pages at
> http://www.gnu.org/philosophy/kragen-software.html
[19] "The equivalent of free software for online services," draft
by Kragen Sitaker, posted to kragen-tol on 2006-07-28
> http://lists.canonical.org/pipermail/kragen-tol/2006-July/000818.html
Referenced in Mike Linksvayer's "Free software needs P2P"
> http://gondwanaland.com/mlog/2006/07/28/free-software-p2p/
and in "open data, APIs, and data formats - lots of small pieces
and a platform" by John Allsopp, 2006-09-04
> http://microformatique.com/?p=22
and in "Was ist ein freier Webdienst? (Beinahe zur??ck aus dem
Urlaub...)", 2006-08-01
> http://log.netbib.de/archives/2006/08/01/was-ist-ein-freier-webdienst-beinahe-zuruck-aus-dem-urlaub/
and in "kragen rides again-", by Luis Villa, 2006-08-05
> http://xent.com/pipermail/fork/Week-of-Mon-20060731/042375.html
[20] Some of Greenspun's writing along these lines is in "A Future
So Bright You'll Need to Wear Sunglasses", one of the chapters of
his book, "Philip & Alex's Guide to Web Publishing", online at
> http://philip.greenspun.com/panda/future
Warning, this page contains photographs of naked women.
[21] "The Other Road Ahead", by Paul Graham, September 2001,
> http://www.paulgraham.com/road.html
[22] "Architectural Styles and the Design of Network-based
Software Architectures", Roy Fielding's doctoral dissertation,
2000; see chapter 5 in particular for the explanation of REST.
> http://roy.gbiv.com/pubs/dissertation/top.htm
[23] "The Rule of Least Power", W3C Technical Architecture Group
Finding, edited by Tim Berners-Lee and Noah Mendelsohn, 2001-02-23
> http://www.w3.org/2001/tag/doc/leastPower.html
[24] The Dojo Toolkit is a successor to, among other things,
NetWindows, and it includes a module system for JavaScript in the
browser.
> http://www.dojotoolkit.org/
[25] JSAN, the JavaScript Archive Network, also has a module
system for JavaScript in the browser; I only know about this
because MochiKit [29] supports both the Dojo and JSAN module
systems.
> http://www.openjsan.org/doc/c/cw/cwest/JSAN/0.10/lib/JSAN.html
> http://use.perl.org/~schwern/journal/24112
[26] "Why Multithreading Sucks, Using Mojo Nation As An Example",
by Zooko O'Whielacronx, 2001-07-17, describing real-world
experience changing from threading to event-driven processing.
> http://www.eros-os.org/pipermail/e-lang/2001-July/005410.html
[27] "Why Threads are a Bad Idea (for most purposes)", by John
C. Ousterhout, 1995-09-28 --- a PowerPoint presentation,
unfortunately.
> http://www.softpanorama.org/People/Ousterhout/Threads/index.shtml
[28] Twisted Python is an industrial-strength framework for
building single-threaded event-driven programs (especially
networked programs) in Python.
> http://www.twistedmatrix.com/
[29] MochiKit is a JavaScript library from some Twisted hackers;
it includes more than Twisted-style asynchronous-event handling
with Deferreds, but it does have that.
> http://mochikit.com/
[30] "The right default: concurrent components with message
passing", by Peter van Roy, on the Lambda the Ultimate blog's
discussion forums, 2004-08-16
> http://lambda-the-ultimate.org/node/view/193
referring to "Concurrent Components With Message Passing"
> http://www.info.ucl.ac.be/~pvr/bookcc.html
[31] The Tamarin project is the integration of Macromedia's
newly-open-source ECMAScript (JavaScript) implementation into the
Mozilla core, in order to make Mozilla (Firefox, Iceweasel,
Thunderbird, etc.) run JavaScript faster. This is the
ActionScript engine from Flash, and it's about an order of
magnitude faster than the JavaScript engine currently in Mozilla.
> http://www.mozilla.org/projects/tamarin/
[32] dojo.storage is part of the Dojo Toolkit [24]. It started
life as "AMASS".
> http://codinginparadise.org/weblog/2006/04/now-in-browser-near-you-offline-access.html
[33] Currently section "5.3. Client-side session and persistent
storage" of "Web Applications 1.0 Working Draft --- 23 November
2006", also known as HTML5.
> http://whatwg.org/specs/web-apps/current-work/#scs-client-side
[34] Since the W3C abandoned the development of the HTML spec in
the wake of the 1990s browser wars, the WHATWG or Web Hypertext
Application Technology Working Group recently began a new version
of the HTML specification:
> http://whatwg.org/specs/web-apps/current-work/
[35] "Client-local storage", currently section 6.1.1 of the "Gecko
1.9 Roadmap", in a "desired" section --- so it may not make it in.
> http://wiki.mozilla.org/Gecko_1.9_Roadmap#Client-local_storage
[36] XUL is an "XML user-interface language" similar to HTML (and
which can embed HTML elements) used for defining UIs for Firefox,
Thunderbird, and other Mozilla apps. You can also load XUL files
in Firefox as web pages. It's just like HTML, but with normal GUI
widgets instead of text.
> http://www.mozilla.org/projects/xul/
[37] "JavaScript sucks ass, part one million", by Donovan Preston,
2005-10-05
> http://ulaluma.com/pyx/archives/2005/10/javascript_suck.html
[38] "JavaScript Sucks (volume 2)", by Bob Ippolito, 2005-07-18;
this explains a lot of the motivation behind creating MochiKit
[29]. See also [39].
> http://bob.pythonmac.org/archives/2005/07/18/javascript-sucks-volume-2/
[39] "JavaScript Sucks (volume 1)", by Bob Ippolito, 2005-06-02;
see also [38].
> http://bob.pythonmac.org/archives/2005/06/02/javascript-sucks-volume-1/
[40] Greasemonkey is a Firefox extension that runs user-specified
bits of JavaScript when web pages load, so that users have as much
control over the page as the page author. It uses "deep
XPCNativeWrappers [42]" to interpose a membrane [41] between the
user's JavaScript and the page's, so that the user's script can do
things the page JavaScript can't, such as talk to other web
servers.
> http://greasemonkey.mozdev.org/
[41] The Membrane Pattern is a common access-control abstraction
in capability security systems; it supports revocability, and in
some circumstances can compensate for violations of security
hygiene by other parts of the system.
> http://www.eros-os.org/pipermail/e-lang/2003-January/008434.html
[42] XPCNativeWrappers are proxy objects used to amplify the
authority (in a capability-security sense) granted by holding a
reference.
> http://kb.mozillazine.org/XPCNativeWrapper
[43] "DHTML persistence: a design for a generic Ajax server-side",
by Kragen Sitaker, 2005-04-10
> http://lists.canonical.org/pipermail/kragen-tol/2005-April/000769.html
[44] Alex Russell publicized the term "Comet," invented by
Jennifer Tharp, to describe a technique independently invented in
1999-2001 by him, some part of the team that started KnowNow
(Rohit Khare, Adam Rifkin, Peyman Oreizy, Dave Long), Brad
Fitzpatrick, Donovan Preston, Just van den Broecke, and probably
several other groups; the technique allows a web server to send
events asynchronously to a web browser by virtue of continuing an
HTTP response for a long time. Alex introduced the term in a talk
at Emerging Technologies Conference 2006, and in a blog post
"Comet: Low Latency Data for the Browser" on 2006-03-03.
> http://alex.dojotoolkit.org/?p=545
[45] Sproutliner is a free-software AJAX outliner with columns,
intended for use as a to-do list.
> http://sproutliner.com/
[46] "MAGNET v0.1", by Gordon Mohr, 2002-06-17, draft of the
MAGNET URI specification for (among other things) linking to files
by content hashes. May or may not be suitable for things like
inline images, since it specifies that the link leads to "a page
of options", not the linked file itself.
> http://magnet-uri.sourceforge.net/magnet-draft-overview.txt
[47] David's Advanced Revision Control System is a radically
decentralized system similar to Arch. [need more explanation]
> http://www.darcs.net/
[48] "Robust Composition: Towards a Unified Approach to Access
Control and Concurrency Control", by Mark Samuel Miller, 2006-05;
describes the capability security landscape more clearly than
anything I've read previously.
> http://www.cypherpunks.to/erights/talks/thesis/markm-thesis.pdf
[49] Ajax is a style of building web applications in which
JavaScript in the web page communicates with the server without
reloading the page; see "Ajax: A New Approach to Web Applications"
by Jesse James Garrett, 2005-02-18
> http://www.adaptivepath.com/publications/essays/archives/000385.php
[50] "NewI\O"
> http://newio.blogspot.com/
[51] "Macromedia Central", by John Dowdell, no date given
> http://www.adobe.com/devnet/jd_forum/jd027.html
[52] A timeline of early Google Maps mashup development; see also
http://en.wikipedia.org/wiki/Google_Maps#Development, which
includes most of these dates.
2005-02-08 Google Maps announced:
> http://news.com.com/Google+finds+its+map+service/2100-1024_3-5567274.html
"Google finds its map service" by Margaret Kane, 2005-02-08
> http://googleblog.blogspot.com/2005/02/mapping-your-way.html
"Mapping your way", by Bret Taylor, 2005-02-08 (the announcement)
2005-03-15 or earlier: Paul Rademacher unveils HousingMaps,
which merges Craigslist apartment listings with Google Maps
> http://www.housingmaps.com/
> http://www.ramsayhome.com/2006/03/15/housingmaps-new-home-research-tool/
"HousingMaps - a web mashup, great for home researching", by
an anonymous author on ramsayhome.com, 2006-03-15
> http://googleblog.blogspot.com/2005/04/bird-view_15.html
"Bird view" by Michael Krantz, 2005-04-15, points at
HousingMaps
> http://ajax.sys-con.com/read/211147.htm
"Founder of HousingMaps.com Drills Down at "Real-World AJAX"
Seminar in San Jose: Paul Rademacher Reveals the
Nitty-Gritty Aspects of Building AJAX Apps", author
anonymous, 2006-04-24
> http://www.newmediamusings.com/blog/2005/05/housingmaps_bri.html
"Housingmaps: brilliant!", by JD Lasica, 2005-05-31
2005-04-09: chicagocrime.org domain first registered, later used
for mashup of Chicago police blotter information and Google
Maps (this date is from whois)
2005-04-19: Adrian Holovaty unveils Chicago Transit Authority
map using Google Maps
> http://www.holovaty.com/blog/archive/2005/04/19/0215
"Chicago Transit Authority map on Google Maps", by Adrian
Holovaty, 2005-04-19
> http://news.com.com/2061-10803_3-5687691.html
"Google Maps, meet Craigslist real estate", by Stephen
Shankland, 2005-04-27, mentions Housingmaps and Adrian
Holovaty's Chicago Transportation Authority maps
2005-05-16 or earlier: Daniel Catt unveils Geobloggers, a mashup
of Flickr with Google Maps; Gregory Sadetsky unveils a mashup
of real-time traffic information with Google Maps
> http://www.wired.com/news/culture/0,1284,67514,00.html
"Hey Google, Map This!", by Daniel Terdiman, 2005-05-16,
mentions that the Google API didn't exist yet at publication
time, and also lists Gregory Sadetsky's traffic-information
mashup, Adrian Holovaty's Chicago transit map, and Daniel
Catt's Geobloggers Flickr/Maps mashup;
2005-05-23 or earlier: Adrian Holovaty (anonymously?) unveils
ChicagoCrime.org, a mashup of Chicago police blotter
information with Google Maps
> http://slashdot.org/articles/05/05/23/115204.shtml
"Google Map Hack & Chicago Crime Data", by Hemos,
2005-05-23, lists HousingMaps and ChicagoCrime.org
2005-06-29: Google announces Google Maps API
>
http://googleblog.blogspot.com/2005/06/world-is-your-javascript-enabled_29.html
"The world is your JavaScript-enabled oyster", by Bret
Taylor, 2005-06-29, announcing the Google Maps API
> http://www.google.com/press/annc/maps_api.html
"Google Maps API", 2005-06-29, by some anonymous illiterate
inside Google, also announcing the Google Maps API
> http://google.dirson.com/post/1444/
"Lanzada la API para Google Maps", by an anonymous author,
2005-06-30, says that Google had just launched a Google Maps
API
[53] "DynamicTyping" by Martin Fowler, 2005-03-14
> http://www.martinfowler.com/bliki/DynamicTyping.html
[54] "Are Dynamic Languages Going to Replace Static Languages?" by
Robert C. Martin, 2003-04-26
> http://www.artima.com/weblogs/viewpost.jsp?thread=4639
[55] "Strong Typing vs. Strong Testing" by Bruce Eckel, 2005-02-03
> http://mindview.net/WebLog/log-0025
[56] "Crossing borders: Delayed binding" by Bruce Tate, 2006-11-07
> http://www-128.ibm.com/developerworks/java/library/j-cb11076.html?ca=drs
[57] "Language Fermentation", by Tim Bray, 2003-05-08
> http://www.tbray.org/ongoing/When/200x/2003/05/08/FutureLanguage
[58] "Duck Typing Defended", by Hans Fugal, 2006-07-08
> http://hans.fugal.net/typo/articles/2006/07/08/duck-typing-defended
