Pushing events to web clients
I'm playing around with pushing events from the server to web based clients. This isn't new stuff of course, it's been around for awhile in the form of things like Pushlets, mod_pubsub and KnowNow.
An interesting approach was raised by Joe Armstrong on the Erlang mailing list. He suggests viewing HTML pages as processes and being able to send messages to them. Followup posts to that message have some interesting ideas as well.
Because I'm lazy and I didn't want to write a lot of client side GUI and Javascript stuff I'm using Backbase for the client side and generating requests to the server. Backbase has some nice abstractions which make this easy to do in a cross-browser friendly manner. For the server side I'm using Yaws and Erlang.
Currently I've got things working whereby you have a web page running on the client, and you can send messages to it from the Erlang server. When a page is displayed in the browser it spawns an Erlang process for that page. This is stored in a lookup table indexed by a random name. Given this name you can get the process id and send it messages. These messages are sent to the browser immediately via a long running connection that is held open between the browser and server.
So assuming a page with the name '12345678' associated with its process, the following code run on the Erlang server causes an alert box to be displayed on the page:
This would allow building an html user interface interactively by executing commands on the server. Any backbase BXML can be sent, or as in the case of the alert example, some of them are abstracted out into messages of their own.
I'm putting together a simple messaging example to put online to demonstrate how it works. It's the usual 'server push' example allowing clients to send messages to other clients and have them displayed immediately.
What other ideas could come from treating HTML pages as processes? Writing clients to Erlang programs could become easier, especially if something like Distel was implemented.
Categories: erlang, backbase, web, yaws
An interesting approach was raised by Joe Armstrong on the Erlang mailing list. He suggests viewing HTML pages as processes and being able to send messages to them. Followup posts to that message have some interesting ideas as well.
Because I'm lazy and I didn't want to write a lot of client side GUI and Javascript stuff I'm using Backbase for the client side and generating requests to the server. Backbase has some nice abstractions which make this easy to do in a cross-browser friendly manner. For the server side I'm using Yaws and Erlang.
Currently I've got things working whereby you have a web page running on the client, and you can send messages to it from the Erlang server. When a page is displayed in the browser it spawns an Erlang process for that page. This is stored in a lookup table indexed by a random name. Given this name you can get the process id and send it messages. These messages are sent to the browser immediately via a long running connection that is held open between the browser and server.
So assuming a page with the name '12345678' associated with its process, the following code run on the Erlang server causes an alert box to be displayed on the page:
process_for('12345678') ! {alert, "Hello"}.This would allow building an html user interface interactively by executing commands on the server. Any backbase BXML can be sent, or as in the case of the alert example, some of them are abstracted out into messages of their own.
I'm putting together a simple messaging example to put online to demonstrate how it works. It's the usual 'server push' example allowing clients to send messages to other clients and have them displayed immediately.
What other ideas could come from treating HTML pages as processes? Writing clients to Erlang programs could become easier, especially if something like Distel was implemented.
Categories: erlang, backbase, web, yaws
posted by Chris Double at 6:19 PM
0 Comments:
Post a Comment
<< Home