[Jderobot-dev] Interfaz Web para TrafficMonitor

redouane kachach redo.robot en gmail.com
Dom Abr 22 20:33:11 CEST 2012 

Buenas Robert,

Primero muchas gracias por la respuesta detallada. He leído/investigado un
poco sobre las tecnologías que propones y la verdad suenan muy bien. Esta
mañana he estado jugando un poco con django (nunca lo habia utlilizado) y
la verdad la capacidad que ofrece es inmensa y permite ahorrar un monton de
tiempo. De lo que estuve leyendo y probando django no soporta por defecto
REST, pero hay librerias que se pueden instalar como apps y que te dan esta
capacidad con un esfuerzo minimo de adaptación, en concreto he encontrado
estas dos:

piston: https://bitbucket.org/jespern/django-piston/wiki/Home
djano-rest-interface: http://code.google.com/p/django-rest-interface/

La gente habla bien del primero, pero eligir entre uno o otro ya lo haremos
en su momento (al menos de que tienes otra alternativa más fiable).

La arquitectura que propones me parece la adequeda y creo que da una buena
abstracción y podremos emplearla en cualquier proyecto. Si la entiendo bien
seria:

Navigador *<< API Rest >> app django* del componente JDEROBOT* << ICE
>>*componente JDEROBOT

Como el app django sera escrito en Python el soporte ICE ya lo tenemos
disponible. La única duda que tengo es en cuanto a componentes JDEROBOT que
guardaran sus datos en una base de datos. En este caso creo podremos
compartir la base de datos entre el componente jderobot y el app django
correspondiente.

Hablando sobre la arquitectura global (no sé si es posible, pero lo dejo
como una idea aver que os parece), lo suyo creo que analizar los tipos de
"controles" que puede tener un componente JDEROBOT, por lo general creo que
estos vienen a ser:

   - Check boxes  (booleanos) y Botones  (booleanos)
   - Barras de desplazamiento (porcentajes, números reales)
   - Listas de elementos
   - Posición del ratón sobre un elemento (integer x,y)
   - etc .. (Seguramente me dejo muchos más controles típicos de un
   componente jderobot.)

Cada componente JDEROBOT que quiere "ser controlado" por un elemento
externo, ofrecerá dos interfaces ICE:

   1. Control
   2. Estado


=== Control ====

En este apartado, lo suyo es tener por lo menos los
siguientes métodos set/get:

        void setModelControl(bool option_1,
                                          bool option_2,
                                          ....)

        void getModelControl(out bool option_1,
                                          out bool option_2,
                                          ....)

=== Estado ====

         void getModelState(out  data_type state_var_1,
                                         out  data_type state_var_2,
                                         ...)

Quizás lo suyo es en vez de un montón de opciones variables de estado, lo
suyo es tener una clases  "Control" y otra "State" que tienen campos para
todas las variables de control/estado del componente, asi si se añade un
nuevo elemento de control o estado, no hay que tocar en 100 ficheros. Con
esto en mente se puede crear un app de django generica, que utiliza estas
interfaces ICE para controlar/obtener el estado de cada componente. Cada
componente JDEROBOT que quiere tener una interfaz Web, tendra que
implementar las interfaces ICE y implementar las "vistas"/representación
correspondientes a sus modelos de datos.

La parte del cliente/navigador la tengo un poco verde, pero imagino que se
puede crear algún componente generico también con Javascript/Jquery para
hablar en REST con el app correspondiente de JDEROBOT ?!

Lo del video/streaming no lo meto de momento en la discusión para no
enrollarnos más de la cuenta ..

Comentarios/Propuestas?!


Muchas gracias,
Redo.

2012/4/3 Roberto Calvo <rocapal en libresoft.es>

>
> 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 adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20120422/912531c1/attachment-0001.htm

More information about the Jde-developers mailing list