two-way communication in html

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.

Received on Friday, 3 March 1995 10:39:44 UTC