Re: two-way communication in html

Pei Wei ([email protected])
Sat, 4 Mar 1995 17:26:01 +0500


> As everybody of us know, html is a "monodirectional" protocol -- in the sense
> that the server cannot initiate a response by itself, but it has to wait
> for a http request from the client.
>
> (no, this is all wrong -- what I want to say is that with a HTML browser
> you have to click to reload a page, otherwise it doesn't happen anything).
>
> I (pronunciation: "my boss") would like to investigate how the thing could
> be changed, in order to have a real "live" environment. Supposing for the
> moment to stick with unix systems and reasonable root powers :-), the first
> ideas which came to me were the following:
[...]
> What do people think about it? All answers are welcome, from "HTML is not
> the Right Means to do that, forget it" to "there is already such and such
> which makes what you propose". Just don't say "You are an idiot who is
> not even good to write in English", please - I do already know it, thanks.
>
> ciao, .mau.

When I was experimenting at getting the HTML/Web more interactive/
proactive, here what I did to make it possible for a web page to become
"active" on its own (not just purely responding to user's events).

*** Connected HTML with a scripting language (Viola script)

With that, you could do tons of stuff... I mean, you've basically got
the capability to program intelligence into your document.

So, for a dumb example, you could link a piece of script to your HTML
which in effect causes the browser to update a document every N seconds.

Or, the script/agent/applet could open a connection to some kind of
"change-notifycation" server, and upon detection of certain conditions,
the script sends a message to the browser telling it to go reload the
document... etc etc etc.

And to make something like Internet Relay Chat on the Web, I wrote this
multi-threaded server (select() based, not OS level m.t.) which acts as a
very simple httpd and message relay.

So, it basically works this way:

* start up ViolaWWW.
* load a chat-applet document, via HTTP, say.
* the chat-applet gets interpreted and built by the viola interpreter.
* the chat-applet connects to the relay server (using its own very simple
protocol), and off you go... you've got a two-way channel to communicate
with other people also looking at the same chat-applet-page using ViolaWWW.

This demo lets you communicate with typed messages and simple picture
sketchings... well, see the paper for a screendump of the demo.

http://berkeley.ora.com/proj/viola/violaIntro.html

That paper's kinda out dated, but... it's there.

It's fully amazing how much wider the scope of things you could do if
you had a scripting language in a browser. Even with a language of
very limited facilities (limited for security reasons).

I'm not sure exactly what you mean by two-way HTML. I can see situations
where it's much better to abstract away whatever we need into HTML,
without the need for a scripting language. That'll probably happen once
we figure out and agree on what we want :)

But one of the points of going with the scripting language approach
is that we don't know all what we're going to need, and a "programming"
language gives you lots of flexibility to deal with new situations.

Pei Wei
([email protected])
Digital Media Group
O'Reilly & Associates, Inc.

PS: The whole setup isn't polished enough for general release. So... But
maybe before too long I'll get enough time and inclination to get it done :)