GUIs - ruby on rails, rico

[Shawn Pearce]

I have done something like this back in the ``old days'' of the
web with Netscape 1.1 (it was around 1995 I guess).  We created a
live chat website which used server-side push to update the client
as soon as a new message was available.  For those who don't know,
server-side push is a special MIME-type created by Netscape and
supported in their browser to allow the server to replace the
content of an image.  This was the first animation on the web,
before animated GIFs came along.

Here is the really old Netscape webpage on the topic:

	http://wp.netscape.com/assist/net_sites/pushpull.html

At the time we were using ``A Patchy Server'' (NCSA + the initial
Apache patches) so prefork was just coming out...  there was no way
A Patchy Server would handle the load from the number of clients
we wanted...  so I wrote our own micro-HTTP server based around
select; pthreads were used to initially accept connections or to
accept send message events from clients; a master distribution
thread used select to push data to all of the server-side push
connections currently active.

Within the client we used HTTP frames (note: not iframes, which today
are better visually) to create a 1 pixel high frame at the bottom
of the window.  JavaScript was used on the client to update the
URL of the bottom frame with a ``message'' to send to the server.
This message was then posted within the 1 pixel high frame.
The result is the server got messages immediately, the user never
saw the page refresh, and everyone else saw the update immediately
after the master distribution thread caught up.


One nice thing was we were able to consistently keep the HTTP
server side push channel open to a client for hours at a time.
It even worked through many HTTP proxy servers.

Problems?  Definately.  Our largest one was the simple fact that
a browser getting data from a server-side push whose current
content boundary hasn't terminated wouldn't always render the
content right away.  See, if you terminate the current part in a
server-side push the client assumes the file is over, and when you
open the next boundary the client will clear the content and start
to redraw again.  So we used only 1 content object in the entire
multipart/x-mixed-replace stream.  Frequent use of <p> tags caused
the clients to redraw pretty much immediately after getting data,
but we needed like 8 <p> tags between messages.  :-)


Many years later I did this again to some extent with iframes; the
client used JavaScript to push data into an iframe (which was then
visually invisible) and the iframe posted content to the server.
The response from the server was HTML+JavaScript to update the
client's DOM tree via DHTML.  Worked like a charm.  But I didn't
reimplement the idea of server side push...  we were looking into
the idea though as we wanted some live feedback indicators in a
few places on the GUI.


I have never used XMLHttpRequest; I think it became available
in Mozilla only after I had finished debugging the iframe
implementation.  :-(


Richard Cameron <camster@REDACTED> wrote:
> 
> On 19 Sep 2005, at 21:00, bryan rasmussen wrote:
> 
> >xmlhttp is an object included with most modern browsers which allows a
> >scripting engine implemented in the browser to make asynchronous http
> >gets, posts etc. it has the name xmlhttp because microsoft who came up
> >with it evidently envisioned it for sending around xml.
> 
> One thing I'd love to do would be to build a message passing library  
> for javascript built on top the XMLHttpRequest which can communicate  
> with a server written in Erlang. The idea would be a sort of analogue  
> of what Distel does for Emacs - it fakes up messages and send/receive  
> primitives in such a way that you can see them in elisp.
> 
> So, typical applications for this library would be web pages which  
> dynamically update when information is "pushed" to them. The simplest  
> toy example might be a stock ticker which updates when the price of  
> the stock actually changes, not just every 60 seconds when the  
> javascript on the web page re-polls. A more ambitious example would  
> be to implement something like SubEthaEdit <http:// 
> www.codingmonkeys.de/subethaedit/> as a pure-web application.  
> SubEthaEdit is quite a clever little Mac OS X application which  
> allows two users on different machines to simultaneously edit the  
> same text file and see the changes appear in real time.
> 
> Unfortunately the only way I can think of to get this to work over  
> HTTP turns out to be a bit of a hack. Luckily though, Erlang is  
> probably ideally placed to cope with the hackiness. Perhaps something  
> like this would do the trick:
> 
> 1) The browser makes an XMLHttpRequest to, say, http://hostname/ 
> encrypted_erlang_process_id/receive
> 2) That request is handled by Yaws which simply sits and waits for  
> any erlang message destined for the browser. If nothing arrives  
> within a suitably conservative http timeout interval (say 30  
> seconds), it returns content back over HTTP to indicate that there  
> are no messages. If any messages are pending, it sends them all down  
> the socket over HTTP under some suitable encoding.
> 3) The browser interprets what it gets back from the XMLHttpRequest  
> and dispatches javascript events corresponding to the underlying  
> Erlang messages. These can handled by the client side javascript. The  
> client then re-polls as in step one, but perhaps acknowledging that  
> it's received the messages so we can have some sort of reliable  
> message delivery system.
> 
> Additionally, the client-side "send" operation could work making  
> XMLHttpRequest to a separate URL, say http://hostname/ 
> encrypted_erlang_process_id/send
> 
> So, of course, the hacky bit is trying to turn the HTTP "pull"  
> protocol into a "push" protocol by having the browser spending all  
> its time sitting with an open socket on port 80 waiting for the  
> server to return the next message. Having several thousand open  
> sockets (one for each connected client) at once is the sort of thing  
> which would utterly kill any apache based server infrastructure, but  
> the Yaws propaganda <http://www.sics.se/~joe/apachevsyaws.html>,  
> support for /dev/poll and kqueue in Erlang on certain architectures,  
> and the whole design of Erlang/OTP indicates that it's probably the  
> right tool for this hack.
> 
> It just strikes me that message passing is probably the right way of  
> thinking when you're trying to build these "AJAX" applications for  
> the web, and if you can get over the particularly grim way of trying  
> to fit it into existing browsers, it might be quite a nice way of  
> working.
> 
> Does anyone know if anyone's already implement anything like this?  
> Would it even work?
> 
> Richard.

-- 
Shawn.

  "The reasonable man adapts himself to the world; the unreasonable one persists
   in trying to adapt the world to himself.  Therefore all progress depends on 
   the unreasonable man."
  -- George Bernard Shaw