GUIs - ruby on rails, rico
Wed Sep 21 14:17:00 CEST 2005
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
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
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/
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
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/
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
Does anyone know if anyone's already implement anything like this?
Would it even work?
More information about the erlang-questions