Buenas, tengo algunos conceptos difusos con la web, así que perdonad si os hago repetir cosas que ya habéis hablado.<div><br></div><div>Primero que nada, veo que hay varios apartados para la web:</div><div><br></div><div>* Página pública de información de un nodo de la PLN. Incluye información sobre el propio nodo u otros nodos de la red. ¿Cómo hacemos esa información dinámica? Una opción sería páginas estáticas, pero el document_root de ese directorio fuera la raiz de un repositorio git, que fuera haciendo pulls frecuentes mediante cron (con lo que obtendría nueva documentación, nuevos nodos incorporados a la red, etc.) No sé si es eso lo que teníais pensado. ¿Qué otras opciones hay?</div>
<div><br></div><div>Por no ampliar la entropía, me gustaría debatir posibles tecnologías con las que implementar la web, a ver qué os parecen.</div><div><br></div><div>* En la capa de diseño/marcado HTML, ¿qué os parece si utilizamos bootstrap[0] como base del marcado/css? ¿Y LESS[1] para el css customizado? Estas dos tecnologías son practicamente un standard en la web hoy en día, y te dan un aspecto visual muy atractivo sin pegarte demasiado con el diseño. Me pareció leer que había alguien metido con el diseño, ¿lee esta lista?</div>
<div><br></div><div>* De cara a dar dinamismo a la capa de cliente, propongo AngularJS como framework MVC javascript. Está desarrollado por Google y parece que supera a BackboneJS[4] que es lo que yo controlaba hasta ahora, yo voto por AngularJS. Otras librerías de más bajo nivel interesantes a utilizar en la capa de cliente pueden ser Underscore[4] y por supuesto jquery[5].</div>
<div><br></div><div>[0] <a href="http://twitter.github.com/bootstrap/">http://twitter.github.com/bootstrap/</a> </div><div>[1] <a href="http://lesscss.org/">http://lesscss.org/</a></div><div>[2] <a href="http://www.angularjs.org/">http://www.angularjs.org/</a></div>
<div>[3] <a href="http://backbonejs.org/">http://backbonejs.org/</a></div><div>[4] <a href="http://underscorejs.org/">http://underscorejs.org/</a></div><div>[5] <a href="http://jquery.com/">http://jquery.com/</a></div><div>
<br></div><div><br></div><div>Otra cosa, he visto que habláis de publicar información en formato CSV. ¿Esto es requerimiento de Asterisk? ¿No podríamos publicar esa misma información en JSON? Es un formato mucho más atacable desde web, desde la capa de cliente podríamos acceder a los datos y presentarlos en el diseño sin tener que parsear nada de una manera cómoda y sencilla.</div>
<div><br></div><div>Veo que también habláis de geolocalizar los nodos con OpenStreetMaps, me parece cojonudo, por eso si definimos un formato de archivo JSON con todos los datos básicos sería fácilmente accesible desde cualquier sitio. Algo del estilo:</div>
<div><br></div><div>wget -q -O /dev/stdout http://<a href="http://patiomaravillas.dyndns.org/patiomaravillas.json">http://patiomaravillas.dyndns.org/patiomaravillas.json</a></div><div><br></div><div>{ name: "patiomaravillas",</div>
<div> dundi_publickey: "<a href="http://patiomaravillas.dyndns.org/patiomaravillas.pub">http://patiomaravillas.dyndns.org/patiomaravillas.pub</a>",</div><div> tinc_publickey: "<a href="http://patiomaravillas.dyndns.org/patiomaravillas">http://patiomaravillas.dyndns.org/patiomaravillas</a>",</div>
<div> position: { "lat": 3.1283872202, "lng": -0.98932823},</div><div> ....</div><div>}</div><div><br></div><div>Sólo con eso ya podríamos generar páginas estáticas, sin necesidad de ningún parser CGI que informaría dinámicamente de todos los nodos de la red.</div>
<div><br></div><div><br></div><div>Finalmente, no nos vamos a librar de utilizar alguna tecnología server-side, no se qué opináis, yo tengo ninguna preferencia, la que más compatibilidad entre nosotros tengamos:</div><div>
<br></div><div>* NodeJS/Express</div><div>* Python/Django</div><div>* PHP/Symphony</div><div>* Ruby/RubyOnRails</div><div><br></div><div>Java no por favor, 8 horas al día currando en java son suficientes :PPPP</div><div><br>
</div><div><br></div><div>He estado investigando sobre las API's de interacción con Asterisk desde la web, he visto que está AJAM[0] y que hay varias implementaciones en distintos lenguajes de programación. A mi el lenguaje/framework que más me motiva ahora mismo es Node/Express, pero la implementación de librería de interacción con AJAM más completa me ha parecido una hecha en Ruby, se llama Adhearsion[1]</div>
<div><br></div><div>[0] <a href="http://www.voip-info.org/wiki/view/Asynchronous+Javascript+Asterisk+Manager+(AJAM)">http://www.voip-info.org/wiki/view/Asynchronous+Javascript+Asterisk+Manager+(AJAM)</a></div><div>[1] <a href="http://adhearsion.com/">http://adhearsion.com/</a></div>
<div><br></div><div>Para redondear el tocho, a ver qué os parece esta idea. Se me ocurre que a modo de Proof-of-concept se podría hacer hacer una demo web similar a lo que en su día impresionaba en la web de jahjah[0]. Básicamente, permitir vía web introducir un número de teléfono de origen y otro de destino, de manera que desemboca en que asterisk llama al origen, lo pone en espera y mientras llama al número de destino para terminar estableciendo la llamada. En su día era la caña, y hoy en día se podría hacer prácticamente gratix.</div>
<div><br></div><div>Esto último es un poco marcianada, pero puede ser útil para coger experiencia en la implementación de webs que interactuen con asterisk, jejeje. </div><div><br></div><div>[0] <a href="http://www.jajah.com/call/trial/">http://www.jajah.com/call/trial/</a></div>
<div><br></div><div>Bueno un saludo</div><div><br></div><div><div class="gmail_quote">El 26 de agosto de 2012 11:13, Santiago Crespo <span dir="ltr"><<a href="mailto:pln-lists.marsupi.org@flanera.net" target="_blank">pln-lists.marsupi.org@flanera.net</a>></span> escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">La idea es que se añadan los usuarios automáticamente a:<br>
<br>
-> sip.conf<br>
-> extensions.conf (si usa alias/nick)<br>
<br>
Y si quiere aparecer en el listín:<br>
<br>
-> local-phonedir.csv<br>
-> pln-phonedir.csv<br>
<br>
Lo del listín "privado" o "medio-público" creo que no es útil, pues si alguien quiere aparecer le interesará estar en el público-público. Además de que sería demasiado fácil que un listín "privado" se haga público en algún momento. ¿Quién sería el responsable, si es un fichero que cualquier admin puede ver/copiar?<br>
<br>
<br>
El 26/08/12 01:58, Blackhold escribió:<div class="im HOEnZb"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2012/8/25 Santiago Crespo <<a href="mailto:pln-lists.marsupi.org@flanera.net" target="_blank">pln-lists.marsupi.org@<u></u>flanera.net</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Perdón, el enlace bueno es:<br>
<br>
<a href="http://patiomaravillas.dyndns.org/local-phonedir.csv" target="_blank">http://patiomaravillas.dyndns.<u></u>org/local-phonedir.csv</a><br>
</blockquote>
mmm ahora mismo se gestionan los usuarios a manija no? la generación<br>
de este fichero podría ser automática, o que lo que se ponga en este<br>
fichero luego sea lo que se cargue a los ficheros de configuración<br>
sip.conf.<br>
ihmo sería absurdo tener que dar de alta el usuario en dos sitios.<br>
<br>
imagino que ahora si tendrá que ser manual, pero no sé como véis la<br>
posibilidad de que este fichero se autogenere (o la config), así<br>
reducimos lo más posible los posibles errores humanos o gazapazos e<br>
disconcordancias...<br>
<br>
que el privado tenga los publicos y los privados, y luego sólo se<br>
pasen al publico los que realmente quieran ser publicos. cat<br>
local-phonedir.csv | grep publico > public-phonedir.csv<br>
<br>
</blockquote>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
PLN mailing list<br>
<a href="mailto:PLN@marsupi.org" target="_blank">PLN@marsupi.org</a><br>
<a href="https://lists.marsupi.org/listinfo/pln" target="_blank">https://lists.marsupi.org/<u></u>listinfo/pln</a><br>
</div></div></blockquote></div><br></div>