[PLN] Ficheros que servirá cada nodo por http

Lun Ago 27 21:09:01 CEST 2012

Buenas, tengo algunos conceptos difusos con la web, así que perdonad si os
hago repetir cosas que ya habéis hablado.

Primero que nada, veo que hay varios apartados para la web:

* 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?

Por no ampliar la entropía, me gustaría debatir posibles tecnologías con
las que implementar la web, a ver qué os parecen.

* 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?

* 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].

[0] http://twitter.github.com/bootstrap/
[1] http://lesscss.org/
[2] http://www.angularjs.org/
[3] http://backbonejs.org/
[4] http://underscorejs.org/
[5] http://jquery.com/

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.

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:

wget -q -O /dev/stdout http://
http://patiomaravillas.dyndns.org/patiomaravillas.json

{ name: "patiomaravillas",
  dundi_publickey: "http://patiomaravillas.dyndns.org/patiomaravillas.pub",
  tinc_publickey: "http://patiomaravillas.dyndns.org/patiomaravillas",
  position: { "lat": 3.1283872202, "lng": -0.98932823},
  ....
}

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.

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:

* NodeJS/Express
* Python/Django
* PHP/Symphony
* Ruby/RubyOnRails

Java no por favor, 8 horas al día currando en java son suficientes :PPPP

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]

[0]
http://www.voip-info.org/wiki/view/Asynchronous+Javascript+Asterisk+Manager+(AJAM)
[1] http://adhearsion.com/

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.

Esto último es un poco marcianada, pero puede ser útil para coger
experiencia en la implementación de webs que interactuen con asterisk,
jejeje.

[0] http://www.jajah.com/call/trial/

Bueno un saludo

El 26 de agosto de 2012 11:13, Santiago Crespo <
pln-lists.marsupi.org en flanera.net> escribió:

> La idea es que se añadan los usuarios automáticamente a:
>
> -> sip.conf
> -> extensions.conf (si usa alias/nick)
>
> Y si quiere aparecer en el listín:
>
> -> local-phonedir.csv
> -> pln-phonedir.csv
>
> 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?
>
>
> El 26/08/12 01:58, Blackhold escribió:
>
>  2012/8/25 Santiago Crespo <pln-lists.marsupi.org@**flanera.net<pln-lists.marsupi.org en flanera.net>
>> >:
>>
>>> Perdón, el enlace bueno es:
>>>
>>> http://patiomaravillas.dyndns.**org/local-phonedir.csv<http://patiomaravillas.dyndns.org/local-phonedir.csv>
>>>
>> mmm ahora mismo se gestionan los usuarios a manija no? la generación
>> de este fichero podría ser automática, o que lo que se ponga en este
>> fichero luego sea lo que se cargue a los ficheros de configuración
>> sip.conf.
>> ihmo sería absurdo tener que dar de alta el usuario en dos sitios.
>>
>> imagino que ahora si tendrá que ser manual, pero no sé como véis la
>> posibilidad de que este fichero se autogenere (o la config), así
>> reducimos lo más posible los posibles errores humanos o gazapazos e
>> disconcordancias...
>>
>> que el privado tenga los publicos y los privados, y luego sólo se
>> pasen al publico los que realmente quieran ser publicos. cat
>> local-phonedir.csv | grep publico > public-phonedir.csv
>>
>>
> ______________________________**_________________
> PLN mailing list
> PLN en marsupi.org
> https://lists.marsupi.org/**listinfo/pln<https://lists.marsupi.org/listinfo/pln>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.marsupi.org/pipermail/pln/attachments/20120827/d5e833c5/attachment-0001.htm>