[PLN] Ficheros que servirá cada nodo por http

Mar Ago 28 23:59:04 CEST 2012

Ok tener una API REST sería lo ideal, es decir, un middleware que ofrezca
de manera sencilla y cristalina una capa de comunicación para el
desarrollador web, y por debajo ya se encargará de hacer las llamadas
correspondientes al AMI o al AJAM  de asterik. Parece lo más razonable y
nos permitirá desacoplar roles, no todos tendremos que saber mucho de todo,
podremos delegar a la capa de debajo, jejeje.

A los que tenéis claro lo que se quiere en la página web pública de un
nodo, os propondría que cogieráis papel y servilleta y dibujaráis un boceto
de lo que debería verse en la página web pública (Internet) de un nodo, sin
pensar en el diseño, sólo las secciones y el tipo de información
representada. Bueno, también podemos utilizar pencil[0] para hacer los
bocetos.

[0] http://pencil.evolus.vn/en-US/Home.aspx

Yo por mi parte he creado un esqueleto de aplicación AngularJS a partir de
angular-seed[0], y le he añadido también bootstrap y un diseño que me ha
parecido aparente para ir haciendo los bocetos, spacelab[1]. No tenemos por
qué quedarnos con bootstrap si no os gusta, pero aunque sea para ir
avanzando en la fase inicial yo creo que nos vendrá muy bien. Sin pegarte
con el css consigues unos diseños la mar de aparentes.

[0] https://github.com/angular/angular-seed
[1] http://bootswatch.com/spacelab/

¿Os parece bien el tema de ir haciendo bocetos y los vamos implementando?
Nos vendrá bien para empezar a perfilar la idea concreta de lo que pretende
el proyecto en el apartado web. Se puede subir a un repositorio github de
momento.

Si alguien se anima a pasar un boceto yo lo implemento en una plantilla
web. Yo empezaría por la web pública de un nodo, que parece lo más sencillo.

Venga un saludo

El 28 de agosto de 2012 00:57, Santiago Crespo <
pln-lists.marsupi.org en flanera.net> escribió:

>  Hola,
>
>
> El 27/08/12 21:09, David Rubert escribió:
>
> 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?
>
>
> La idea es que cada nodo mantenga unos ficheros con los listados de:
>
> * nodos PLN
> * usuarios PLN
> * usuarios locales
> * info del nodo local
> * y otros, ver  http://pad.marsupi.org/plnfiles
>
> Por ejemplo, para actualizar el listado de nodos y de usuarios de la PLN,
> cada X un script descarga el listado de usuarios locales y los datos de
> todas las IPs de la VPN que respondan.
>
> Opcionalmente, un admin de un nodo podría decidir que en vez de mapear él
> mismo toda la red, descargará simplemente los ficheros que haya generado
> otro nodo que sí que mapee la red cada X
>
>
>
> 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.
>
>
> Puse CSV por ser algo fácilmente parseable y que ocupa lo justo. +1 a usar
> JSON, creo que el tiempo de los programadores vale más que los Mb que
> puedan llegar a ocupar de más el listado de usuarios.
>
>
>
>  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.
>
>
> +1 , pero que el fichero con la información del nodo tenga un nombre
> genérico, por ejemplo pln-node.json
>
> Así los scripts podrán descargar éste fichero sin conocer el nombre del
> nodo, sólo con un wget a su IP en la VPN.
>
>
>
>
>  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/
>
>
> Estaría genial algo así :D
>
> Teléfono de origen: número tradicional PSTN
> Teléfono destino: número PLN
>
> Otra: que en los resultados de la búsqueda del listín aparezca junto al
> teléfono un icono de llamar y que te dé opción de llamar desde el navegador
> o introducir tu teléfono tradicional.
>
> :D
>
> Saludos,
> Santiago Crespo.
>
> _______________________________________________
> PLN mailing list
> PLN en marsupi.org
> 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/20120828/2cb3d461/attachment-0001.htm>