<div class="gmail_extra">Buenas Robert,</div><div class="gmail_extra"><br></div><div class="gmail_extra">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:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">piston: <a href="https://bitbucket.org/jespern/django-piston/wiki/Home" target="_blank">https://bitbucket.org/jespern/django-piston/wiki/Home</a> </div><div class="gmail_extra">
djano-rest-interface: <a href="http://code.google.com/p/django-rest-interface/" target="_blank">http://code.google.com/p/django-rest-interface/</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">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).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Navigador <b><font color="#ff0000"><< API Rest >></font> app django</b> del componente JDEROBOT<b><font color="#ff0000"> << ICE >></font></b> componente JDEROBOT</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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:</div>
<div class="gmail_extra"><ul><li>Check boxes (booleanos) y Botones (booleanos)</li><li>Barras de desplazamiento (porcentajes, números reales)</li><li>Listas de elementos</li><li>Posición del ratón sobre un elemento (integer x,y)</li>
<li>etc .. (Seguramente me dejo muchos más controles típicos de un componente jderobot.)</li></ul></div><div class="gmail_extra">Cada componente JDEROBOT que quiere "ser controlado" por un elemento externo, ofrecerá dos interfaces ICE:</div>
<div class="gmail_extra"><ol><li>Control</li><li>Estado</li></ol></div><div class="gmail_extra"><br></div><div class="gmail_extra">=== Control ====</div><div class="gmail_extra"><br></div><div class="gmail_extra">En este apartado, lo suyo es tener por lo menos los siguientes métodos set/get:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"><div class="gmail_extra"> void setModelControl(bool option_1,</div><div class="gmail_extra"> bool option_2,</div>
<div class="gmail_extra"> ....)</div><div class="gmail_extra"><br></div><div class="gmail_extra"> void getModelControl(out bool option_1,</div><div class="gmail_extra"> out bool option_2,</div>
<div class="gmail_extra"> ....)</div><div class="gmail_extra"><br></div><div class="gmail_extra">=== Estado ====</div><div class="gmail_extra"><br></div></div><div> void getModelState(out data_type state_var_1, </div>
</div><div class="gmail_extra"><div> out data_type state_var_2, </div><div> ...)</div></div><div class="gmail_extra"> </div><div class="gmail_extra">
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. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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 ?!</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Lo del video/streaming no lo meto de momento en la discusión para no enrollarnos más de la cuenta .. </div><div class="gmail_extra"><br></div><div class="gmail_extra">
Comentarios/Propuestas?!</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Muchas gracias,</div><div class="gmail_extra">Redo.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
<div class="gmail_quote">2012/4/3 Roberto Calvo <span dir="ltr"><<a href="mailto:rocapal@libresoft.es" target="_blank">rocapal@libresoft.es</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Buenas Redo,<br>
<br>
Te cuento un poco mis impresiones que además ya había comentado a Jose<br>
María porque salió este tema para otros proyectos.<br>
<br>
Los requisitos que comentas me parecen genial, además añadiría el de<br>
crear este interfaz web o infraestructura de manera genérica. Hemos<br>
detectado muchas más apps de jderobot que la utilizarían.<br>
<br>
Mis comentarios/propuesta va por añadir una capa más a cualquier<br>
aplicación JDEROBOT. Entendemos aplicación JDEROBOT como un conjunto de<br>
componentes que se comunican mediante ICE y tienen una función concreta<br>
(en tu caso trafficmonitor, pero también está suverillace, eldercare y<br>
otras).<br>
<br>
Esta capa de abstracción la haría mediante API REST, por ejemplo esta<br>
DJANGO que es un framwork desarrollado en python para facilitar esta<br>
tarea. API REST viene a ser HTTP, y se suele utilizar JSON y XML para<br>
intercambiar datos. Digamos que es lo moderno y lo nuevo con respecto a<br>
webservices (SOAP/WSDL), cgis y todas esas tecnologías.<br>
<br>
Tenemos por tanto el API REST, que posee todas las características de la<br>
aplicación (no hablo de componentes, sino de aplicación). Es posible que<br>
no toda la funcionalidad de componentes queramos exportarla para gente<br>
que quiera hacer apps externas o visores. O incluso por seguridad.<br>
Teniendo el API REST es muy muy sencillo realizar una interfaz web en<br>
html5/javascript o programar un cliente Android/iPhone para acceder a<br>
información básica del sistema.<br>
<br>
Y si, es posible desde Android y desde un navegador con PHP acceder a<br>
objetos ICE e interactuar, pero creo que para aplicaciones como<br>
eldercare, trafficmonitor o surveillance, es necesario una capa de<br>
abstracción que nos diga qué podemos utilizar y qué no del sistema (eso<br>
lo conseguimos con DJANGO y API REST). Además utilizamos tecnologías que<br>
la gente conoce y las apps salen como churros.<br>
<br>
Más o menos es como lo veo:<br>
<br>
|-- WebApp<br>
Componentes ICE -> API REST ->|-- AndroidApp<br>
|-- Etc<br>
<br>
Sobre todo veo esta arquitectura para aplicaciones reales y con un fin<br>
muy concreto. Toda la comunicación entre componentes ice y el api rest<br>
se realiza mediante ICE. Toda la comunicación entre API rest y<br>
aplicaciones de terceros se realiza mediante HTTP utilizando ficheros<br>
JSON/XML. Estándar a tope! :-)<br>
<br>
<br>
Sobre el tema del vídeo creo que no importa la arquitectura, elijamos la<br>
que elijamos habrá ese problema. Al final es un problema de como<br>
comunicar ICE con el browser. HTML5 ofrece muchas maneras para realizar<br>
streaming y reproducción de vídeo. Van muy bien y en tiempo real, el<br>
problema es que aun que es estándar a día de hoy no todos los<br>
navegadores lo tienen implementado y funcionando al 100%. Todo el<br>
software que conozco de webcams que tienen página web para ver su cámara<br>
utilizan un activeX para visualizar el vídeo en tiempo real.<br>
Aunque si la solución pasa porque el componente guarde la imagen<br>
enriquecida, con el API REST se soluciona muy fácil sin scripts en<br>
python. Simplemente tienes una llamada http /image/ que devuelve la<br>
imagen, y la llamas cuantas veces quieras desde el navegador (con código<br>
html y javascript puedes decir que cada X segundos se realice una<br>
petición y actualice un DIV o IMG).<br>
<br>
Quizás con las demás ideas que vayan saliendo podemos reunirnos un día y<br>
vemos con más detalle las opciones.<br>
<br>
Un saludete!<br>
<br>
El dom, 19-02-2012 a las 15:20 +0100, redouane kachach escribió:<br>
<div><div>> Bueno, acabo de ver que PHP tiene una extensión para soportar ICE, asi<br>
> que podria tambien ser una alternativa para desarrollar la interfaz<br>
> 1):<br>
><br>
><br>
> <a href="http://www.zeroc.com/icephp.html" target="_blank">http://www.zeroc.com/icephp.html</a><br>
><br>
><br>
><br>
> 2012/2/19 redouane kachach <<a href="mailto:redo.robot@gmail.com" target="_blank">redo.robot@gmail.com</a>><br>
> Buenos días compañer@s,<br>
><br>
><br>
> Estos días estos explorando alternativas para desarrollar una<br>
> interfaz web para la aplicación TrafficMonitor. La idea es<br>
> desarrollar una interfaz web para facilitar el acceso a la<br>
> aplicación desde cualquier sitio. Todo esto manteniendo la Gui<br>
> existente de GTK.<br>
><br>
><br>
> <a href="http://www.youtube.com/watch?v=MvPY1CBapE4" target="_blank">http://www.youtube.com/watch?v=MvPY1CBapE4</a><br>
> <a href="http://www.jderobot.org/index.php/User:Redo" target="_blank">http://www.jderobot.org/index.php/User:Redo</a><br>
><br>
><br>
> La actual interfaz hecha en GTK consiste (como podéis ver en<br>
> el vídeo) en un conjunto de checkboxes para<br>
> hablitar/deshabilitar las diferentes funcionalidades de la<br>
> aplicación, con alguno que otro slide. Para la parte de<br>
> configuración tengo las siguientes dudas:<br>
><br>
><br>
> 1) Como conectar el servidor Web con la applicación del<br>
> TrafficMonitor: En este apartado habia pensado en utilizar CGI<br>
> + PHP o Javascript para procesar la configuración y luego<br>
> mandarla a la app del TrafficMonitor. En cuanto a la interfaz<br>
> entre el script CGI y el TrafficMonitor no tengo claro que<br>
> utilizar. En este caso se me occuren las siguientes<br>
> alternativas:<br>
</div></div>> * Una interfaz XML para describir los distintos<br>
> parametros de configuración<br>
> * Una interfaz propia con algun protocolo propio para<br>
<div>> mandar los distintos parametros de configuración<br>
><br>
><br>
> 2) La segunda duda que tengo es como mandar el video que<br>
> genero para mostrarlo en la interfaz web). El video es<br>
> básicamente el mismo que viene desde el cameraserver + cosas<br>
> que dibujo por encima utilizando Cairo. Hasta el momento he<br>
> conseguido volcar el video del DrawingArea a una imagen (JPEG,<br>
> pero hay más formatos disponibles). Aqui no sé cual es la<br>
> mejor opción:<br>
</div>> * Utilizar el snapshot + algun opcion de refresco<br>
<div>> (javascript o PHP) para forzar el servidor a que<br>
> refreseque solo la imagen en la interfaz. He hecho<br>
> unas pruebas báscicas con esta opción y no me acaba de<br>
> gustar. El video "parpadea" por mucho que baje el rate<br>
> de refresco. El problema persiste incluso haciendo uso<br>
> de dos imagenes con un link symbolico para alternar<br>
> entre una y otra a medida que se van construyendo.<br>
</div>> * No sé si es posible generar un stream de video del<br>
<div>> snapshot que voy guardando. Si esto es posible, se<br>
> podra utilizar algun protocol standard de streaming<br>
> para mostrar el video en la interfaz Web.<br>
><br>
><br>
> Otra alternativa que he visto por hay es utilizar Websevices<br>
> (sobre todo para implementar la interfaz 1)). Ahora bien, no<br>
> he entrado mucho en detalle para ver que cosas se pueden hacer<br>
> con esta tecnologia.<br>
><br>
><br>
> La solución eligida al final me gustaria que respete los<br>
> siguientes criterios:<br>
</div>> 1. Lo más estandard posible y que dependa de<br>
> tecnologias/SW ampliamente soportado.<br>
> 2. El cliente no tenga que instalar nada raro. Deberia<br>
<div>> poder acceder a la interfaz con un simple browser.<br>
</div>> 3. Tiempo real (sobre todo para el video que se esta<br>
> mostrando en la web).<br>
> 4. Los compnentes/modulos SW deberian esta disponible<br>
<div>> bajo la GPL o una licenacia compatible.<br>
><br>
><br>
> En cuanto al servidor Web pienso utilizar lighthttpd<br>
> (<a href="http://www.lighttpd.net/" target="_blank">http://www.lighttpd.net/</a>) he liedo buena critica del mismo,<br>
> lo he probado y la verdad el setup básico no requiere mucha<br>
> configuración. Otra alternativa es Apache, pero quizas para lo<br>
> que necesito no me hace falta tanta potencia.<br>
><br>
><br>
> Cualquier ayuda/sugerencia/alternativa es más que bienvenida.<br>
><br>
><br>
> Muchas gracias de antemano,<br>
> Redo.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
</div><div><div>> _______________________________________________<br>
> Jde-developers mailing list<br>
> <a href="mailto:Jde-developers@gsyc.es" target="_blank">Jde-developers@gsyc.es</a><br>
> <a href="http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers" target="_blank">http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers</a><br>
<br>
</div></div><span><font color="#888888">--<br>
Roberto Calvo Palomino | Libre Software Engineering Lab (GSyC)<br>
R&D Android Mobile Engineer | Universidad Rey Juan Carlos<br>
Tel: <a href="tel:%28%2B34%29%2091%20488%2087%2073" value="+34914888773" target="_blank">(+34) 91 488 87 73</a> | Edif. Biblioteca - Despacho B103<br>
<a href="http://libresoft.es/" target="_blank">http://libresoft.es/</a> | Camino del Molino s/n - 28943 (Madrid)<br>
<br>
GPG-KEY: <a href="http://gsyc.es/~rocapal/rocapal.gpg" target="_blank">http://gsyc.es/~rocapal/rocapal.gpg</a><br>
</font></span></blockquote></div><br></div>