librelist archives

Re: [erlar] divaguemos un poco?

From:

Nahuel Greco

Date:

2012-01-25 @ 16:17

Creo haber leído a Joe Armstrong rumbeando para ese lado usando
websockets. También es un poco lo que trata de hacer Nitrogen, de
forma más primitiva. Me parece que el mayor problema con el que te
podes encontrar es que para muchas cosas siempre va a ser más
eficiente que no haya un roundtrip hasta el server, eso te va a
limitar lo que podes hacer en erlang puro. Me parece que para no caer
en esa limitación lo mejor sería hacer una VM en javascript que corra
un subset de Erlang, y así tendrías Erlang end-to-end, con el DOM
siendo manipulado tanto desde el Erl corriendo en el browser como el
Erl corriendo en el server. Me parece haber visto también un proyecto
"jsbeam" o algo así para reimplementar la VM en js.

Saludos,
Nahuel Greco.



2012/1/25 Mariano Guerra <luismarianoguerra@gmail.com>:
> buenas, tengo esta idea en la cabeza y no he tenido el tiempo de
> probarla asi que les comento y vemos que sale (y por ahi se unen y la
> empezamos :)
>
> la idea es simple (?).
>
> que pasa si modelamos el DOM del navegador como un actor de erlang que
> recibe determinados mensajes y manipula el DOM y genera eventos,
>
>  la estructura interna permite enchufar otros actores en nodos y
> propagar los mensajes a estos (de esa forma podemos tener muchos
> actores chiquitos y "componerlos" en uno mas grande).
>
> hasta ahora todo aburrido, pero...
>
> si modelamos los mensajes similares por ejemplo a la api de jquery
> pero como datos y permitimos que el actor "forwardee" los mensajes a
> un websocket que tambien esta del lado del cliente y escribimos en js
> una libreria que manipule el DOM del lado del cliente en base a los
> mismos mensajes entonces podemos programar en erlang y tener cambios
> en el cliente sin escribir js! (excepto la libreria obvio)
>
> tambien esto nos permite tener una version del lado del servidor que
> podemos mantener por un tiempo y si el cliente vuelve simplemente le
> podemos pedir al actor que mande al cliente la version actual del dom
> (esto permitiria que la pagina sea completamente dinamica pero que
> google la pueda scrapear).
>
> incluso le podemos decir al actor que simule un click en un boton y lo
> mande al cliente tambien y cosas asi.
>
> tambien podemos hacer lo opuesto, mandar los eventos del cliente al
> servidor como mensajes, procesarlos en el server y mandar los mensajes
> de vuelta para que se reflejen los cambios.
>
> otra cosa interesante de esto es que podemos tener un log de que paso
> en la pagina mientras el usuario interactuaba, reproducirla si salto
> un bug o hacer dumps periodicos del dom para inspeccionar algo.
>
> espero que se haya entendido algo de lo que digo, pero me parece que
> la idea esta interesante.
>
> diganme que opinan y que piensan que esta bien/mal mejorable o por
> donde podria ir.
>
> saludos!

2012/1/25 Nahuel Greco <ngreco@gmail.com>:
> Creo haber leído a Joe Armstrong rumbeando para ese lado usando
> websockets.

si, lo lei, lo que no me gusta es que el manda codigo javascript por
el socket y hace eval en el navegador.

perdon por la expresion pero eso es medio feito :)

> También es un poco lo que trata de hacer Nitrogen, de
> forma más primitiva. Me parece que el mayor problema con el que te
> podes encontrar es que para muchas cosas siempre va a ser más
> eficiente que no haya un roundtrip hasta el server, eso te va a
> limitar lo que podes hacer en erlang puro.

mi filosofia ultimamente es "hacer cosas copadas sin importarme mucho
por las optimizaciones", sino no estariamos escribiendo erlang :)

> Me parece que para no caer
> en esa limitación lo mejor sería hacer una VM en javascript que corra
> un subset de Erlang, y así tendrías Erlang end-to-end, con el DOM
> siendo manipulado tanto desde el Erl corriendo en el browser como el
> Erl corriendo en el server. Me parece haber visto también un proyecto
> "jsbeam" o algo así para reimplementar la VM en js.

esto es parecido a lo que quieren hacer en clojure con clojurescript,
yo no quiero traducir codigo, es valido, pero por algo eso no funciona
tan bien. De hecho pense en traducir efene a js, pero algunas cosas
como tail recursion y paternmatching lo hacen bastante complejo.

yo quiero una caja negra que reciba mensajes y reaccione con
implementaciones en erlang y js, entonces podes hacer las cosas en
cualquier lado y forwardear los mensajes y tenes lo mismo de los dos
lados, imaginate:

Dom ! {text, "#usuario", "bienvenido " ++ Usuario}

su equivalente en js seria

dom.bang(D.Text, "#usuario", "bienvenido" + usuario);

con lo que si recibis el mensaje por un websocket o lo generas del
lado del cliente da igual, si viene del server haces

dom.bang.apply(dom, msg);

y listo, tenes el mismo comportamiento :)

esto te permite decidir de que lado lo queres hacer o incluso podes
bufferear muchos mensajes y enviarlos todos juntos o generarlos en el
server y mandar el dump del dom, o mandar el dom inicial y una lista
de eventos que el cliente ejecuta en un loop:

msgs.forEach(function (msg) { dom.bang.apply(dom, msg) });

sigo divagando :)

saludos!

Después de leer esto se me viene a la cabeza, manipulación del dom
multi client con un solo buffer en el server, uno modifica en el
browser, se modifica en el server y se sincroniza con todos los demás
browser :D

2012/1/26 Roger Duran <rogerduran@gmail.com>:
> Después de leer esto se me viene a la cabeza, manipulación del dom
> multi client con un solo buffer en el server, uno modifica en el
> browser, se modifica en el server y se sincroniza con todos los demás
> browser :D

si, otra de las cosas interesantes que se pueden hacer.

imaginate que puedas ver lo que el cliente esta haciendo y ayudarlo, o
dr un tutorial. o sharear una presentacion :D

2012/1/25 Mariano Guerra <luismarianoguerra@gmail.com>:
> 2012/1/25 Nahuel Greco <ngreco@gmail.com>:
>
> perdon por la expresion pero eso es medio feito :)
>

Si, es mandar evals es feo.

> yo quiero una caja negra que reciba mensajes y reaccione con
> implementaciones en erlang y js, entonces podes hacer las cosas en
> cualquier lado y forwardear los mensajes y tenes lo mismo de los dos
> lados, imaginate:
>
> Dom ! {text, "#usuario", "bienvenido " ++ Usuario}
>
> su equivalente en js seria
>
> dom.bang(D.Text, "#usuario", "bienvenido" + usuario);
>
> con lo que si recibis el mensaje por un websocket o lo generas del
> lado del cliente da igual, si viene del server haces
>
> dom.bang.apply(dom, msg);
>
> y listo, tenes el mismo comportamiento :)
>
> esto te permite decidir de que lado lo queres hacer o incluso podes
> bufferear muchos mensajes y enviarlos todos juntos o generarlos en el
> server y mandar el dump del dom, o mandar el dom inicial y una lista
> de eventos que el cliente ejecuta en un loop:
>
> msgs.forEach(function (msg) { dom.bang.apply(dom, msg) });


Tiene algo similar a lo que hace Nitrogen, donde los eventos de los
elementos del DOM están predefinidos y podes handlearlos / pattern
matchearlos tanto en el server como en el cliente. Lo viste? La
diferencia principal sería que Nitrogen no mantiene un DOM del lado
del server.

Saludos,
Nahuel Greco.

PD: dale un vistazo a esto:


http://groups.google.com/group/erlang-programming/browse_thread/thread/a73efebabf352d19#
https://github.com/joearms/SEBG

Saludos,
Nahuel Greco.



2012/1/25 Nahuel Greco <ngreco@gmail.com>:
> Creo haber leído a Joe Armstrong rumbeando para ese lado usando
> websockets. También es un poco lo que trata de hacer Nitrogen, de
> forma más primitiva. Me parece que el mayor problema con el que te
> podes encontrar es que para muchas cosas siempre va a ser más
> eficiente que no haya un roundtrip hasta el server, eso te va a
> limitar lo que podes hacer en erlang puro. Me parece que para no caer
> en esa limitación lo mejor sería hacer una VM en javascript que corra
> un subset de Erlang, y así tendrías Erlang end-to-end, con el DOM
> siendo manipulado tanto desde el Erl corriendo en el browser como el
> Erl corriendo en el server. Me parece haber visto también un proyecto
> "jsbeam" o algo así para reimplementar la VM en js.
>
> Saludos,
> Nahuel Greco.
>
>
>
> 2012/1/25 Mariano Guerra <luismarianoguerra@gmail.com>:
>> buenas, tengo esta idea en la cabeza y no he tenido el tiempo de
>> probarla asi que les comento y vemos que sale (y por ahi se unen y la
>> empezamos :)
>>
>> la idea es simple (?).
>>
>> que pasa si modelamos el DOM del navegador como un actor de erlang que
>> recibe determinados mensajes y manipula el DOM y genera eventos,
>>
>>  la estructura interna permite enchufar otros actores en nodos y
>> propagar los mensajes a estos (de esa forma podemos tener muchos
>> actores chiquitos y "componerlos" en uno mas grande).
>>
>> hasta ahora todo aburrido, pero...
>>
>> si modelamos los mensajes similares por ejemplo a la api de jquery
>> pero como datos y permitimos que el actor "forwardee" los mensajes a
>> un websocket que tambien esta del lado del cliente y escribimos en js
>> una libreria que manipule el DOM del lado del cliente en base a los
>> mismos mensajes entonces podemos programar en erlang y tener cambios
>> en el cliente sin escribir js! (excepto la libreria obvio)
>>
>> tambien esto nos permite tener una version del lado del servidor que
>> podemos mantener por un tiempo y si el cliente vuelve simplemente le
>> podemos pedir al actor que mande al cliente la version actual del dom
>> (esto permitiria que la pagina sea completamente dinamica pero que
>> google la pueda scrapear).
>>
>> incluso le podemos decir al actor que simule un click en un boton y lo
>> mande al cliente tambien y cosas asi.
>>
>> tambien podemos hacer lo opuesto, mandar los eventos del cliente al
>> servidor como mensajes, procesarlos en el server y mandar los mensajes
>> de vuelta para que se reflejen los cambios.
>>
>> otra cosa interesante de esto es que podemos tener un log de que paso
>> en la pagina mientras el usuario interactuaba, reproducirla si salto
>> un bug o hacer dumps periodicos del dom para inspeccionar algo.
>>
>> espero que se haya entendido algo de lo que digo, pero me parece que
>> la idea esta interesante.
>>
>> diganme que opinan y que piensan que esta bien/mal mejorable o por
>> donde podria ir.
>>
>> saludos!

y a esto, Erlang in the Browser: https://github.com/baryluk/erljs

Saludos,
Nahuel Greco.



2012/1/25 Nahuel Greco <ngreco@gmail.com>:
> PD: dale un vistazo a esto:
>
> 
http://groups.google.com/group/erlang-programming/browse_thread/thread/a73efebabf352d19#
> https://github.com/joearms/SEBG
>
> Saludos,
> Nahuel Greco.
>
>
>
> 2012/1/25 Nahuel Greco <ngreco@gmail.com>:
>> Creo haber leído a Joe Armstrong rumbeando para ese lado usando
>> websockets. También es un poco lo que trata de hacer Nitrogen, de
>> forma más primitiva. Me parece que el mayor problema con el que te
>> podes encontrar es que para muchas cosas siempre va a ser más
>> eficiente que no haya un roundtrip hasta el server, eso te va a
>> limitar lo que podes hacer en erlang puro. Me parece que para no caer
>> en esa limitación lo mejor sería hacer una VM en javascript que corra
>> un subset de Erlang, y así tendrías Erlang end-to-end, con el DOM
>> siendo manipulado tanto desde el Erl corriendo en el browser como el
>> Erl corriendo en el server. Me parece haber visto también un proyecto
>> "jsbeam" o algo así para reimplementar la VM en js.
>>
>> Saludos,
>> Nahuel Greco.
>>
>>
>>
>> 2012/1/25 Mariano Guerra <luismarianoguerra@gmail.com>:
>>> buenas, tengo esta idea en la cabeza y no he tenido el tiempo de
>>> probarla asi que les comento y vemos que sale (y por ahi se unen y la
>>> empezamos :)
>>>
>>> la idea es simple (?).
>>>
>>> que pasa si modelamos el DOM del navegador como un actor de erlang que
>>> recibe determinados mensajes y manipula el DOM y genera eventos,
>>>
>>>  la estructura interna permite enchufar otros actores en nodos y
>>> propagar los mensajes a estos (de esa forma podemos tener muchos
>>> actores chiquitos y "componerlos" en uno mas grande).
>>>
>>> hasta ahora todo aburrido, pero...
>>>
>>> si modelamos los mensajes similares por ejemplo a la api de jquery
>>> pero como datos y permitimos que el actor "forwardee" los mensajes a
>>> un websocket que tambien esta del lado del cliente y escribimos en js
>>> una libreria que manipule el DOM del lado del cliente en base a los
>>> mismos mensajes entonces podemos programar en erlang y tener cambios
>>> en el cliente sin escribir js! (excepto la libreria obvio)
>>>
>>> tambien esto nos permite tener una version del lado del servidor que
>>> podemos mantener por un tiempo y si el cliente vuelve simplemente le
>>> podemos pedir al actor que mande al cliente la version actual del dom
>>> (esto permitiria que la pagina sea completamente dinamica pero que
>>> google la pueda scrapear).
>>>
>>> incluso le podemos decir al actor que simule un click en un boton y lo
>>> mande al cliente tambien y cosas asi.
>>>
>>> tambien podemos hacer lo opuesto, mandar los eventos del cliente al
>>> servidor como mensajes, procesarlos en el server y mandar los mensajes
>>> de vuelta para que se reflejen los cambios.
>>>
>>> otra cosa interesante de esto es que podemos tener un log de que paso
>>> en la pagina mientras el usuario interactuaba, reproducirla si salto
>>> un bug o hacer dumps periodicos del dom para inspeccionar algo.
>>>
>>> espero que se haya entendido algo de lo que digo, pero me parece que
>>> la idea esta interesante.
>>>
>>> diganme que opinan y que piensan que esta bien/mal mejorable o por
>>> donde podria ir.
>>>
>>> saludos!