Re: two-way communication in html

Vinay Kumar (vinay@eit.COM)
Fri, 3 Mar 1995 15:48:56 +0500


Check out some of the work we have done. Shared Mosaic is being built
to create a peer-to-peer environment for "real-time" information access.
Some documentation is available at,
http://www.eit.com/software/mosaic/shared-mosaic.html

Right now it is human driven on remote site, but the architecture is
not tied to this specific metaphor.

Is the project done ? No not yet !
Are we still working on this ? Yes ! and will be finishing real soon now
....:)

Enjoy,

---
 Vinay Kumar
vinay@eit.com
	"Bringing Real Time Network Media To The Desktop"
<std/disclaimer.h>
> From www-talk@www10.w3.org  Fri Mar  3 08:15:23 1995
> From: mau@beatles.cselt.stet.it (Maurizio Codogno)
> 
> 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.
>