GUIs - ruby on rails, rico

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.
> 