GUIs - ruby on rails, rico

[Richard Cameron]

On 21 Sep 2005, at 15:15, Joe Armstrong (AL/EAB) wrote:

>    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

... and you could take this approach to its logical extreme if you're  
interested in building these really dynamic "AJAX" style applications  
like, for example:

http://www.meebo.com/
http://www.protopage.com/

(the second doesn't seem to like Safari, so you'd need Firefox or  
even IE)

Any browser not completely past its sell-by date will make available  
the contents of the DOM for inspection and manipulation in  
javascript.  So that's what's happening when these applications  
dynamically create little floating "div" things which look like  
windows. They even appear to be dragable by means lots of behind-the- 
scenes javascript. When you combine this with XMLHttpRequest, you can  
update little bits of content dynamically from the server without  
having to regenerate the entire HTML page from the template and send  
it over the network again.

So, if instead of writing your template engine (the thing which spits  
out fully rendered HTML) as a server-side Erlang thing, you just bit  
the bullet and implemented it in Javascript then you could have this  
sort of _Title@REDACTED ! "this is a blog"_ construct actually update the  
page on the browser as the user looks at it. Your web application  
turns out to be an Erlang process which keeps track of the raw data  
which can be sent down to the browser which simply displays it. So an  
immediately useful consequence of all this is that you could write,  
for example, a blog posting page with a large textbox which can auto- 
save your work such that you don't lose it all when you accidentally  
close the window, or your browser crashes - you've kept the state on  
the server. It's even vaguely "Model-View-Controller" buzzword  
compliant, it's just the view happens to live on a completely  
different machine.

Actually, looking on the blogs, it seems that the instant messaging  
application is implementing pretty much exactly this distributed  
message passing approach:

http://plasser.net/blog/continuous_ajax_requests/
http://blog.meebo.com/?p=23

All the javascript to do this seems to be highly embedded into their  
application, but it ought to be fairly easy to develop a stand-alone  
library which implements the message passing primitives - exactly  
like Distel, but in a browser. Clearly the real magic is going to  
happen on the server side though. Erlang is the "right" language to  
think about about writing applications which control the UI by some  
distributed message passing protocol. It's also going to handle the  
load a whole lot better than an apache/python implementation.

>     Now all I have to do is implement it - pretty easy given erlang  
> and rico
> like stuff.

... yes. I'm having exactly the same problem. Always much more  
difficult when you have to actually do the work.

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

Yes, you can define your own protocol and do what you like with it.  
The reason it's called "XML" is because the object has a property  
called "responseXML". If your messages are well-formed XML then you  
can use the browser's built-in operations to traverse the document  
tree and generally process the data. There's some argument that the  
performance benefit of using the native operations in the browser to  
do this (rather than implementing a parser which has to run as  
interpreted javascript) might even be worth the cost of lugging lots  
of verbose XML over the network[*]. All depends on what's in your  
messages I suppose. If you're transporting complex Erlang expressions  
then there's a reasonable term <-> lisp s-expression <-> XML mapping  
which might mean that you end up with something the browser can  
actually manipulate at the other end without having to write your own  
erlang term parser in javascript. The downside to all that is that  
different XML libraries are available in different browsers, so you  
have bit of a nightmare checking it's all cross-platform.

Richard.

[*] - although the standard trick of compressing verbose content with  
zlib as it's actually transported over the network should work fine  
here. See <http://httpd.apache.org/docs/2.0/mod/mod_deflate.html> for  
an Apache implementation.