<br><br><div class="gmail_quote">On Wed, Dec 19, 2012 at 4:53 PM, Christopher Meiklejohn <span dir="ltr"><<a href="mailto:cmeiklejohn@basho.com" target="_blank">cmeiklejohn@basho.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wednesday, December 19, 2012 at 6:58 AM, Joe Armstrong wrote:<br>
> > But how the browser understand the commands you send from erlang process? for<br>
> > example here: {cmd, fill_div}<br>
><br>
><br>
> This is easy, here's an overview:<br>
><br>
> - Convert the Erlang command to JSON<br>
> - send the JSON on the websocket uing Erlang<br>
> - receive the JSON in Javascript<br>
> - parse the JSON<br>
> - build a Javascript command<br>
> - execute the Javascript command<br>
<br>
<br>
</div>Hi Joe,<br>
<br>
Thank you for putting this out there, I had a great time digging through the source code learning how the examples worked.<br>
<br>
I found it so inspiring that I went off and started playing around with some alternative approaches to handling the messages on the JavaScript side.  See here: [1]<br>
<br>
I've been exploring having the messages, when received on the JavaScript side, distributed using a pub/sub approach so the Erlang code doesn't have to know about JavaScript function names or argument lists.  I felt this made it feel a bit less RPC-ish and made it feel a bit more idiomatic.  See below for examples.<br>

<br>
One thing that I couldn't get a hold of when playing with your code was if you intended to write *most* of the client side application in Erlang and just write a thin-layer in JavaScript for event handling and DOM-manipulation or if you were leaving that up to the developer.<br>
</blockquote><div><br></div><div>It depends on the application - if you look at the viserl1.html</div><div>it's all JavaScript and no Erlang - I was just playing around - I think for latency</div><div>reasons you have to handle events in the browser (like drag and drop).</div>
<div><br></div><div>For a complex application I'd view the bowser as a black box that did things then invent my own protocol to get it to do things.</div><div><br></div><div>In another experiment I just made a page with one function on it that</div>
<div>just does eval to anything you send it - this is just *too* general - but then</div><div>again you'd only ever need one web page for *everything* </div><div><br></div><div>/Joe</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Again, thanks so much!<br>
<br>
--<br>
<br>
For example (partially taken from the README):<br>
<br>
Given the following Erlang:<br>
<br>
BrowserPid ! {client_count, 1}.<br>
<br>
The following message is sent on the wire:<br>
{ type: "client_count", message: "1" }<br>
<br>
Followed by the following message published via AmplifyJS:<br>
amplify.publish("client_count", 1);<br>
<br>
This allows multiple consumers in your JavaScript application to subscribe to these messages and respond to them accordingly.  A subscriber could then call a method to update the DOM with that new value (via jQuery or whatever, this is no longer specific).<br>

<br>
[1] <a href="https://github.com/cmeiklejohn/piper" target="_blank">https://github.com/cmeiklejohn/piper</a><br>
<br>
--<br>
<br>
Christopher Meiklejohn<br>
Software Engineer<br>
Basho Technologies, Inc.<br>
<br>
<br>
</blockquote></div><br>