two-way communication in html

Maurizio Codogno (mau@beatles.cselt.stet.it)
Fri, 3 Mar 1995 10:56:32 +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:

(1) add a background process which polls every x seconds the server to check
for a new (content of a) page
(2) try and integrate http server functionalities in the browser, to get
announcement of new data
(3) start a http client&server in the local machine and devise some way
to communicate between the browser and the http daemon.

Now solution (1) is of course really simple to code, and it work fine for most
applications, but it could generate unnecessary load, and besides I don't
like it very much. Solution (2) seems to mix two very different things at
a logical level, and it should be avoided. Solution (3) in a certain sense
just moves the problem, since we have yet to think about how to make
an interaction between the browser and the http daemon, but at least this
has become a "local" solution.

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.