Client-side scripts

	   -----------------------------------------------
		    "HyperText Scripting Language"

The recent discussions of client-side image maps, extensions to the
ISMAP-capability, client-side highlighting, etc. suggest that the time
is slowly getting ripe for client-side scripting. By that I mean a
bold leap away from all those half-hearted HTML extensions into a
completely new language.

In the past we have had discussions about all kinds of `safe' variants
of languages such as Scheme, Tcl, Python, and C. Those discussions
were probably premature and I'm not even sure that we know enough
about the Web now to do better, but still, another round of
discussions cannot hurt.

So, to stimulate some thought, here are my ideas, in random order, and
untested.

1. Let's be ambitious: take the best features of existing browsers,
CGI scripts, and stand-alone multi-media products and extrapolate as
far as you can. Then ask: what language do we need to send all this
over the wire plus:

  - animated algorithms with user settable parameters

  - text that slips away when you try to click on it

  - thumbnail HTML pages that circle each other on the screen

  - a complete browser for images in YAIF format

  - an update for your browser's HTML editor that auto-installs

  - a news-flash that updates itself every 5 minutes

  - a ticking clock that displays the users's local time

  - a `screen saver' for your browser's window

  - a script to get a page from somewhere & add highlighting

2. Obviously, the language must be `safe' (to the level chosen by the
user), but it should also be distributable in both source and binary
form. That is, we standardize on a `Uniform Object Code' (or bytecode,
or p-code, or...) and define a high-level language along with it.
Binary distribution should provide some form of protection against
plagiarism. Emulator technology has matured enough to make a UOC
interpreter feasible, with negligible loss of speed.

3. Make it (i.e., the suggested high-level language) a language that
*really* supports reusable code, through much restricted OOP: instance
variables are never exported, not even to subclasses; memory
management is automatic, through garbage collection; type checking
cannot be evaded, not even the run-time checking can be disabled.

4. Define an API consisting of the services that a program in this
language can expect to be present in its environment. This includes
such things as getting a document by URL, managing windows, displaying
a document in format X, etc. This could be in the form of a set of
classes, from which a program is created by subclassing.

5. Apart from a small kernel, you could even write the browser itself
in this language.

6. The language would solve the problems mentioned in the first
paragraph:

  - client-side image maps: the SRC-attribute of the IMG tag doesn't
    refer to an image, but to a script that, in turn, retrieves the
    image, displays it in its allocated sub-window and processes the
    user's mouse clicks.

  - multi-click imagemaps: ditto

  - client-side highlighting: current index servers generate a page of
    HTML with the search results, usully in the form of hyperlinks to
    the requested documents. New servers would generate a script
    instead, that included not only the list of URLs, but also the
    logic to modify a document after the user has retrieved it.

7. Difficult question: when a document is static, pressing the `Back'
button is unambiguous: you go back to exactly the same document that
you saw earlier. But if that document is dynamic, do you go back to
the state you left it in, to its start state, or does the `document'
continue to evolve even while you don't look at it? The examples above
of the news flash and the clock seem to suggest that the document
continues to evolve. But what if you go back to a document that has
long been removed from the browser's memory?

On the other hand, maybe this isn't such a difficult question after
all. In my browser I've made a distinction between short-term and
long-term memory: a certain number of pages is still there, though
hidden by newer ones. They have left a visual trace and when that
trace disappears you know that the page has fallen off the edge and
has to be reloaded if you want to go back to it. As long as that trace
is there, you don't go `back', you just bring it to the front.

8. One of the examples above already mentioned it: when you want to
distribute your data in some non-standard form, you can now do so:
just ship the reader along with the document. Its like those
self-extracting archives, which you can use even if you don't have
zip, arc, zoo, etc.

9. So far, I've talked about applications where the purpose of the
script was to interact with the user. Maybe the language can be used
to implement those much-hyped `agents' as well. Maybe you can collect
some scripts that you can send off to a server to run under its wings
for a while, negotiating and processing information before contacting
its home base again and passing on what it learned. Once you have a
program with good algorithms for deciding what information is useful
and what not, you can send the program instead of typing in a complex
boolean query.

10. The culture of the printed document has forced on us the use of
2-dimensional, static logos on letterheads, home pages, even in the
corners of television screens. Why not create moving logos?  A logo in
the corner of your HTML document that exhibits recognizable behaviour
instead of having a recognizable form.



Bert
-- 
                          Bert Bos                      Alfa-informatica
                 <bert@let.rug.nl>           Rijksuniversiteit Groningen
    <http://www.let.rug.nl/~bert/>     Postbus 716, NL-9700 AS GRONINGEN

Received on Tuesday, 7 March 1995 14:06:15 UTC