{5} Assigned, Active Tickets by Owner (Full Description) (44 matches)

Actualmente los paquetes debian facilitan poco la configuración de servidores EzWeb. Por ejemplo, actualmente solo tienen en cuenta el uso de apache2 como servidor para EzWeb, a lo que se añade que solo se permite configurar una instancia de EzWeb (que aunque puede decirse que es la configuración más típica, no es del todo descabellado tener dos o más instancias en una misma máquina). Es más, de los diversos parámetros de configuración que admite la plataforma EzWeb, solo se puede configurar el nombre del servidor.

Todo esto hace que sea necesario crear un sistema para configurar de forma más flexible las instancias de EzWeb. Esto permitirá que los paquetes den soporte a varios tipos de servidores (lighttpd, apache2, etc..), a diversas bases de datos (postgres, mysql, sqlite3, etc..), etc...

Ver #97, #190

Esta tarea consiste en:

• Proporcionar la interfaz para editar las preferencias de los IGadgets en el Dragboard.
• Realizar todos los cambios necesarios para que el mecanismo de notificación y persistencia de las preferencias.

Currently only SQLite3 is supported by Debian package. This task is aimed to support MySQL DBMS also in a package called ezweb-platform-postgres.

Cuando se esté en modo de compusición de mashup (unlocked), se debe poder cambiar el nombre del igadget. Este nuevo nombre debe verse tanto en el drabboard como en el wiring GUI.

Crear un modelo Django que implemente el modelo de datos diseñado

Diseño del API REST para el acceso al modelo del catálogo Implementacion del fichero uris.py de Django Implementación del fichero views.py de Django exportando el contenido de la base de datos.

Aportar a la plataforma mecanismos que permitan aportar contenidos de usuario

WIKI / BLOG / commentarios... ...

Revisando el funcionamiento del catálogo se han observado diversas anomalías que deberían ser mejoradas:

* Cuando se muestran los detalles de un recurso del catálogo e intentas ver los slots y eventos disponibles, en vez mostrarse el nombre de los canales disponibles se muestra su friendcode. Pero sin embargo, al intentar realizar una búsqueda pinchando sobre el enlace, la búsqueda se realiza a partir del nombre del canal, en vez de buscar a partir de su friendcode. Este funcionamiento debería se completamente inverso: se debería mostrar el nombre del canal, pero la búsqueda al hacer click sobre el enlace debería realizarse sobre el friencode.

* He observado un segundo problema en la interfaz de búsqueda avanzada: cuando intentas buscar un slot o evento, la búsqueda únicamente se realiza a partir de su friendcode, esta búsqueda debería incluir también el nombre del canal, ya que un usuario final no tiene porqué conocer el friencode de un canal.

Adapting the already ported iGadgets to previous Resource Architecture

Código.

Esta tarea se desglosará en subtareas.

Implementar los mecanismos de comunicación gadget-plataforma.

Dos aspectos a destacar:

• Gestión de la comunicación entre gadgets, persistencia de varaibles y propiedades.
• Petición de informaión sobre la plataforma por parte de los gadgets (usuario, características del entonro de ejecución, versión de navegador, etc)

Mirar documento #22

Fecha de comienzo: 27/09/2007

Strucutring SVN folders, adding headers to files, etc

Fallos generales a arreglar.

Implementación del módulo y sus operaciones de acuerdo a las especificaciones y diseños realizados.

Montar una pagina web en el raiz que incluya todas los ficheros JS que forman la plataforma

* Se extiende el modelo de datos para contemplar el concepto de gadget contratable! Generalizado a Capabilities * El catálogo, se conecta al HomeGatewayDispatcher? para descargar el listado de gadgets disponibles para el usuario de ezweb. Esos gadgets, están disponibles en función de los dispositivos que tenga el usuario encendidos en su pasarela residencial.

Este ticket se corresponde con la tarea de implementar la estructura básica (sólo los atributos) de la clase Connectable y todas las demás clases que heredan de ella.

Al menos se deberá notificar en este ticket cuando los atributos sean definitivos (es decir, se haya incluido lo necesario para la persistencia).

Subticket de #27

Este ticket se corresponde con la tarea de desconexión entre conectables disponibles en el módulo wiring. Contemplamos como desconexiones simples únicamente una desconexión entre un objeto de la clase In y un objeto de la clase InOut?, o entre un obejto InOut? y otro Out

Al menos es necesario notificar en este ticket cuando se haya completado esta tarea.

Subticket de #27

Definición de Arquitectura de Alto Nivel indicando la comunicación con la plataforma.

Documentación liberada en la wiki-Trac

Este ticket se corresponde con la tarea de definir las estructuras que gestiona la clase Wiring del módulo de idéntico nombre, así como implementarlas. Además tienen que estar implementados tambien los métodos de creación y eliminación de canales que proporciona el interfaz de esta clase.

Al menos es necesario notificar en este ticket cuando se haya completado esta tarea.

Subticket de #27

Este ticket se corresponde con la tarea de borrados entre conectables disponibles en el módulo wiring. Los borrados de conexiones complejas involucran los borrados de canales o de gadgets, en cuyo lugar hay ue eliminar las conexiones mutuas, evitando que haya conexiones muertas con ojbetos inexistentes.

Al menos es necesario notificar en este ticket cuando se haya completado esta tarea.

Subticket de #27

Este ticket se corresponde con la tarea de definir e implementar la persistencia del módulo. Para ello definimos las estructuras de los datos en JSON y los métodos callback para recuperación de la información del servidor.

Al menos es necesario notificar en este ticket cuando se haya completado esta tarea.

Subticket de #27