GUIs - ruby on rails, rico

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

Joe Armstrong (AL/EAB)

  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 ! "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 ! {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@Page ! " some text "

   I can query a receptor with !!

        ie Title !! 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
> [mailto:owner-erlang-questions]On Behalf Of Richard Cameron
> Sent: den 21 september 2005 14:17
> To: rasmussen.bryan
> Cc: Martin Carlson; erlang-questions
> 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.
>


Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

Shawn Pearce
"Joe Armstrong (AL/EAB)" <joe.armstrong> wrote:
>     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.

Because XML is coooooool.  Or something like that.  Management will
purchase anything with a hot buzzword in it, if they had just
called it HTTPRequest it wouldn't have gotten management buy-in,
as everything was about XML at the time.  SOAP was especially cool
around 1999.  But SOAPHTTPRequest might have been considered to be
too specific, so XMLHTTPRequest it is...

Why is Erlang called Erlang?  :-) Why is Internet Explorer not
called Automatic Virus Downloader?

--
Shawn.

  "We learn from history that we learn nothing from history."
  -- George Bernard Shaw


Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

Richard Cameron-2
In reply to this post by Joe Armstrong (AL/EAB)

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


Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

Christian S
In reply to this post by Joe Armstrong (AL/EAB)
2005/9/21, Joe Armstrong (AL/EAB) <joe.armstrong>:
>     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.

Because of this method on the object:
  readonly attribute Document                responseXML

[From http://www.whatwg.org/specs/web-apps/current-work/#scripted-http]

It was probably believed that XML would be the best and the only way for message
passing.  There are alternatives such as JSON.

[JSON http://www.crockford.com/JSON/index.html]

I guess nothing stops us from just calling the object HttpRequest...
except the induced
confusion.


Reply | Threaded
Open this post in threaded view
|

GUIs - ruby on rails, rico

David Hopwood-2
In reply to this post by Shawn Pearce
Shawn Pearce wrote:

> "Joe Armstrong (AL/EAB)" <joe.armstrong> wrote:
>
>>    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.
>
> Because XML is coooooool.  Or something like that.  Management will
> purchase anything with a hot buzzword in it, if they had just
> called it HTTPRequest it wouldn't have gotten management buy-in,
> as everything was about XML at the time.

Why would it need to get management buy-in? This is low-level stuff that should
be left to the techies in any sanely run company...

(...oh, right, I see what assumption I'm making ;-)

> SOAP was especially cool around 1999.  But SOAPHTTPRequest might have been
> considered to be too specific, so XMLHTTPRequest it is...
>
> Why is Erlang called Erlang?  :-)

<http://en.wikipedia.org/wiki/Agner_Krarup_Erlang>

> Why is Internet Explorer not called Automatic Virus Downloader?

Dunno.

--
David Hopwood <david.nospam.hopwood>