[Jderobot-dev] Interfaz Web para TrafficMonitor
Roberto Calvo
rocapal en libresoft.es
Mar Abr 3 18:26:17 CEST 2012
Buenas Redo,
Te cuento un poco mis impresiones que además ya habÃa comentado a Jose
MarÃa porque salió este tema para otros proyectos.
Los requisitos que comentas me parecen genial, además añadirÃa el de
crear este interfaz web o infraestructura de manera genérica. Hemos
detectado muchas más apps de jderobot que la utilizarÃan.
Mis comentarios/propuesta va por añadir una capa más a cualquier
aplicación JDEROBOT. Entendemos aplicación JDEROBOT como un conjunto de
componentes que se comunican mediante ICE y tienen una función concreta
(en tu caso trafficmonitor, pero también está suverillace, eldercare y
otras).
Esta capa de abstracción la harÃa mediante API REST, por ejemplo esta
DJANGO que es un framwork desarrollado en python para facilitar esta
tarea. API REST viene a ser HTTP, y se suele utilizar JSON y XML para
intercambiar datos. Digamos que es lo moderno y lo nuevo con respecto a
webservices (SOAP/WSDL), cgis y todas esas tecnologÃas.
Tenemos por tanto el API REST, que posee todas las caracterÃsticas de la
aplicación (no hablo de componentes, sino de aplicación). Es posible que
no toda la funcionalidad de componentes queramos exportarla para gente
que quiera hacer apps externas o visores. O incluso por seguridad.
Teniendo el API REST es muy muy sencillo realizar una interfaz web en
html5/javascript o programar un cliente Android/iPhone para acceder a
información básica del sistema.
Y si, es posible desde Android y desde un navegador con PHP acceder a
objetos ICE e interactuar, pero creo que para aplicaciones como
eldercare, trafficmonitor o surveillance, es necesario una capa de
abstracción que nos diga qué podemos utilizar y qué no del sistema (eso
lo conseguimos con DJANGO y API REST). Además utilizamos tecnologÃas que
la gente conoce y las apps salen como churros.
Más o menos es como lo veo:
|-- WebApp
Componentes ICE -> API REST ->|-- AndroidApp
|-- Etc
Sobre todo veo esta arquitectura para aplicaciones reales y con un fin
muy concreto. Toda la comunicación entre componentes ice y el api rest
se realiza mediante ICE. Toda la comunicación entre API rest y
aplicaciones de terceros se realiza mediante HTTP utilizando ficheros
JSON/XML. Estándar a tope! :-)
Sobre el tema del vÃdeo creo que no importa la arquitectura, elijamos la
que elijamos habrá ese problema. Al final es un problema de como
comunicar ICE con el browser. HTML5 ofrece muchas maneras para realizar
streaming y reproducción de vÃdeo. Van muy bien y en tiempo real, el
problema es que aun que es estándar a dÃa de hoy no todos los
navegadores lo tienen implementado y funcionando al 100%. Todo el
software que conozco de webcams que tienen página web para ver su cámara
utilizan un activeX para visualizar el vÃdeo en tiempo real.
Aunque si la solución pasa porque el componente guarde la imagen
enriquecida, con el API REST se soluciona muy fácil sin scripts en
python. Simplemente tienes una llamada http /image/ que devuelve la
imagen, y la llamas cuantas veces quieras desde el navegador (con código
html y javascript puedes decir que cada X segundos se realice una
petición y actualice un DIV o IMG).
Quizás con las demás ideas que vayan saliendo podemos reunirnos un dÃa y
vemos con más detalle las opciones.
Un saludete!
El dom, 19-02-2012 a las 15:20 +0100, redouane kachach escribió:
> Bueno, acabo de ver que PHP tiene una extensión para soportar ICE, asi
> que podria tambien ser una alternativa para desarrollar la interfaz
> 1):
>
>
> http://www.zeroc.com/icephp.html
>
>
>
> 2012/2/19 redouane kachach <redo.robot en gmail.com>
> Buenos dÃas compañer en s,
>
>
> Estos dÃas estos explorando alternativas para desarrollar una
> interfaz web para la aplicación TrafficMonitor. La idea es
> desarrollar una interfaz web para facilitar el acceso a la
> aplicación desde cualquier sitio. Todo esto manteniendo la Gui
> existente de GTK.
>
>
> http://www.youtube.com/watch?v=MvPY1CBapE4
> http://www.jderobot.org/index.php/User:Redo
>
>
> La actual interfaz hecha en GTK consiste (como podéis ver en
> el vÃdeo) en un conjunto de checkboxes para
> hablitar/deshabilitar las diferentes funcionalidades de la
> aplicación, con alguno que otro slide. Para la parte de
> configuración tengo las siguientes dudas:
>
>
> 1) Como conectar el servidor Web con la applicación del
> TrafficMonitor: En este apartado habia pensado en utilizar CGI
> + PHP o Javascript para procesar la configuración y luego
> mandarla a la app del TrafficMonitor. En cuanto a la interfaz
> entre el script CGI y el TrafficMonitor no tengo claro que
> utilizar. En este caso se me occuren las siguientes
> alternativas:
> * Una interfaz XML para describir los distintos
> parametros de configuración
> * Una interfaz propia con algun protocolo propio para
> mandar los distintos parametros de configuración
>
>
> 2) La segunda duda que tengo es como mandar el video que
> genero para mostrarlo en la interfaz web). El video es
> básicamente el mismo que viene desde el cameraserver + cosas
> que dibujo por encima utilizando Cairo. Hasta el momento he
> conseguido volcar el video del DrawingArea a una imagen (JPEG,
> pero hay más formatos disponibles). Aqui no sé cual es la
> mejor opción:
> * Utilizar el snapshot + algun opcion de refresco
> (javascript o PHP) para forzar el servidor a que
> refreseque solo la imagen en la interfaz. He hecho
> unas pruebas báscicas con esta opción y no me acaba de
> gustar. El video "parpadea" por mucho que baje el rate
> de refresco. El problema persiste incluso haciendo uso
> de dos imagenes con un link symbolico para alternar
> entre una y otra a medida que se van construyendo.
> * No sé si es posible generar un stream de video del
> snapshot que voy guardando. Si esto es posible, se
> podra utilizar algun protocol standard de streaming
> para mostrar el video en la interfaz Web.
>
>
> Otra alternativa que he visto por hay es utilizar Websevices
> (sobre todo para implementar la interfaz 1)). Ahora bien, no
> he entrado mucho en detalle para ver que cosas se pueden hacer
> con esta tecnologia.
>
>
> La solución eligida al final me gustaria que respete los
> siguientes criterios:
> 1. Lo más estandard posible y que dependa de
> tecnologias/SW ampliamente soportado.
> 2. El cliente no tenga que instalar nada raro. Deberia
> poder acceder a la interfaz con un simple browser.
> 3. Tiempo real (sobre todo para el video que se esta
> mostrando en la web).
> 4. Los compnentes/modulos SW deberian esta disponible
> bajo la GPL o una licenacia compatible.
>
>
> En cuanto al servidor Web pienso utilizar lighthttpd
> (http://www.lighttpd.net/) he liedo buena critica del mismo,
> lo he probado y la verdad el setup básico no requiere mucha
> configuración. Otra alternativa es Apache, pero quizas para lo
> que necesito no me hace falta tanta potencia.
>
>
> Cualquier ayuda/sugerencia/alternativa es más que bienvenida.
>
>
> Muchas gracias de antemano,
> Redo.
>
>
>
>
>
>
>
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
--
Roberto Calvo Palomino | Libre Software Engineering Lab (GSyC)
R&D Android Mobile Engineer | Universidad Rey Juan Carlos
Tel: (+34) 91 488 87 73 | Edif. Biblioteca - Despacho B103
http://libresoft.es/ | Camino del Molino s/n - 28943 (Madrid)
GPG-KEY: http://gsyc.es/~rocapal/rocapal.gpg
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre : no disponible
Tipo : application/pgp-signature
Tamaño : 198 bytes
Descripción: This is a digitally signed message part
Url : http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20120403/665dcc23/attachment.pgp
More information about the Jde-developers
mailing list