- From: Pei Wei <wei@ora.com>
- Date: Sat, 4 Mar 1995 17:22:36 -0500
- To: mau@beatles.cselt.stet.it
- Cc: dale@ruby.ora.com, johnl@ruby.ora.com, lisag@ruby.ora.com, www-talk@www10.w3.org
> 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 (wei@ora.com) 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 :)
Received on Saturday, 4 March 1995 17:23:16 UTC