GUIs - ruby on rails, rico

[Richard Cameron]

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.