GUIs - ruby on rails, rico
Joe Armstrong (AL/EAB)
joe.armstrong@REDACTED
Wed Sep 21 16:15:46 CEST 2005
Yes - this is exactly right.
In my "latest and best" web/blog/information thingy is based of the idea
of viewing web pages as processes (remember "everything in Erlang is a process")
So a blogger template looks likes this:
<html>
<head> ...
<title>${Title}$</title>
<script> ... </script>
<table>
... ${SideBar}$ ...
... ${Blogs}$ ...
... ${Footer}$
</html>
Of course, there is *lots* of crap here but this thing to note is
is this a kind of abstraction. But what sort of abstraction?
My first blogger viewed a template as a lambda abstraction. ie the
${Title}$ etc in the template are just variables which need to be filled in.
So this page is a just a function of the free variables ${Title}$ ${Blogs}$ etc.
A more interesting way to view the template is as a process. The variables
represet *place markers* to which "things" can be sent.
To create a page I say
Page = create_page(templateName)
Then I can fill in the data
Title@REDACTED ! "this is a blog"
This sends a "this is a blog" message to the ${Title}$ receptor in Page
So I can fill in the values of the fields by sending message to the page.
For the recursive case I can send templates to the receptors.
So
Blog@REDACTED ! {template, "foo"} - puts a foo template inb the Blog receptor
of Page.
If the template foo has receptors X and Y then I can send message to these as well
X@REDACTED@Page ! " some text "
I can query a receptor with !!
ie Title@REDACTED !! read
is shorthand for an RPC that reads the title from page.
This all gets to be rather fun in a distruibuted environment.
Now all I have to do is implement it - pretty easy given erlang and rico
like stuff.
BTW - why is it called XMLHTTP? - as far as I can see there is absolutly no
requirement for the server responding to requests with XML - the server can reply with
any old string that it feels like, and a javascript receptor can do anything
it feels like with the result.
/Joe
> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Richard Cameron
> Sent: den 21 september 2005 14:17
> To: rasmussen.bryan@REDACTED
> Cc: Martin Carlson; erlang-questions@REDACTED
> Subject: Re: GUIs - ruby on rails, rico
>
>
>
> 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.
>
More information about the erlang-questions
mailing list