 Buenos días. Mi nombre es Sebastián Ortega y voy a hacer una presentación sobre Morfeo EasyWeb, una plataforma de MassApp software libre, si alguien se queda claro. Trabajo para la Universidad Politécnica de Madrid y tenemos una participación en la plataforma de software libre Morfeo que intenta unir esfuerzos para crear software libre en distintos campos. En primer lugar voy a hacer una pequeña introducción a los conceptos que hay detrás de la plataforma. Después hablaremos del estado actual del proyecto y finalmente veremos algunas interioridades del proyecto. Bueno, una de las ideas fundamentales detrás del proyecto es la larga cola que ha sido citada en la charla anterior y que es un concepto introducido por Timorilli y forma parte, es una parte central de lo que se entiende la web 2.0, las comunidades y cómo funciona gran parte del comportamiento humano. La larga cola hace referencia a aquellas distribuciones de gran número de cosas en las que los mayores, por ejemplo, los primeros elementos en frecuencia son mucho mayores que el resto, es decir, el ejemplo inicial era en productos como libros en los que los best sellers realmente no son en volumen los libros más vendidos por Amazon, realmente venden mucho más de esos libros menos frecuentes, porque los gustos de la gente se suelen distribuir utilizando estas funciones. Este también es uno de los principios que hay detrás del modelo del Bazar. También es una parte integral de la cultura libre, del software libre. Eris Raymond en su libro La Catedral y el Bazar hablaba sobre modelos de desarrollo basados en la contribución de la gente que se distribuyen de esta forma y la idea es poder adquirir quizás menos contribuciones pero de más gente y poder aprovecharse de menos conocimiento de gente con menos conocimiento técnico pero mucha más cantidad de gente y a la larga eso va a poder producir mucha mayor contribución. La distribución de long-tail tradicional tiene esta forma y por ejemplo aplicado a las aplicaciones las aplicaciones las podemos ordenar de mayor a menor especificidad en cuanto a cómo destrecho son los requisitos. De esta forma las primeras aplicaciones en esta distribución son las que mayor número de usuarios pueden aprovecharse de ellas y que su explotación comercial puede producir un mayor retorno de beneficio. Sin embargo, esto lo que produce es que el desarrollo tradicional de software privativo solo permita que se creen esas aplicaciones y que no sean viables el resto de aplicaciones. Es decir, no es posible utilizar las técnicas de ingeniería de software tradicionales por el coste que llevan para la mayor parte de las posibles aplicaciones. Con lo cual estas aplicaciones no pueden ser desarrolladas con estos modelos. Sin embargo, si pudiésemos reducir los costes o pudiésemos aprovecharnos de las contribuciones de una mayor cantidad de gente, es decir, con una menor barrera de entrada, muchas más aplicaciones serían posibles. En el mismo sentido podemos pensar en organizar por grado de habilidad técnica a los posibles usuarios o miembros de una comunidad. Al principio de la distribución tendríamos a la posible base de desarrolladores. Es decir, la gente con la suficiente capacidad técnica como para poder analizar las fuentes del kernel y enviar un parche o decidir que una característica de una aplicación puede ser mejorada o directamente se les ocurre que se pueda realizar esa contribución y son capaces de realizarla. Sin embargo, la mayor parte de los usuarios de una comunidad no van a poder realizar contribuciones de esta forma. Por lo tanto, se puede liberar una gran cantidad de potencial si se reduce esas barreras y, por ejemplo, proporcionando otro tipo de actividades. La mayor parte de la comunidad no va a poder desarrollar parches. Sin embargo, si van a poder contribuir con traducciones o van a poder contribuir enviando informes de error o van a poder realizar otras cosas. El concepto pasa por reducir, no necesitar un nivel elevado de habilidad o ciertos conocimientos técnicos para poder realizar una contribución. Y de esa forma se podrá liberar mucho potencial que está en la comunidad o en el grupo de usuarios y que de otra forma no podría ser conseguido. Bueno, esto, como ya hemos dicho, tiene mucho impacto también en el modelo desarrollo de las aplicaciones. Las aplicaciones web tradicionales son desarrolladas siguiendo el modelo de la catedral. Es decir, hay un grupo restringido de desarrolladores que trabaja en secreto o independientemente y de vez en cuando o cada mucho tiempo, dependiendo, hace una release de software dependiendo ya del modelo si es software libre, liberarán también el código fuente si no software libre, liberarán solo la página web o la aplicación o lo que sea. Y realmente en este modelo hay una contribución de un personal muy específico y muy restringido. Este es el modelo tradicional del software privativo y también de algunos software libres o era el principio del movimiento de software libre. Por ejemplo, al principio el desarrollo del propio IMAX era un modelo de catedral. El otro modelo, el del Bazar, consiste en que el desarrollo se haga en abierto. Es decir, todo el desarrollo es visible por la comunidad en todo momento, está abierto a la contribución y cada persona puede intentar enviar parches, comentar y realizar una contribución. No hay un proceso dirigido o, por lo menos, no tan restringido como la anterior. Y Eric Clemon tomó la metáfora del Bazar, en el que hay un batiburrillo de tenderetes puestos, la gente va de una a otra, regatea y hay unas propiedades emergentes por las que las estructuras surgen por sí mismas. Este modelo es mucho más apropiado para las aplicaciones web basadas en MassApp o composicionales, que es realmente el tipo de aplicaciones en las que intenta cubrir el proyecto EasyWeb. Y bien, exactamente ¿qué es EasyWeb? Como bien dice esta transparencia, EasyWeb es una plataforma de MassApp que permite la composición de aplicaciones web a partir de gadgets. Muy bien, ¿qué es MassApp? Un MassApp es un recurso posiblemente basado en web, está entre paréntesis porque no es necesario, sin embargo, ahora veremos qué es muy conveniente, en el que estos recursos se combinan y los recursos son provenientes de distintas fuentes, como en un Bazar en el que existe interacción de muchos actores. Entonces, realmente, en esta definición de MassApp caen muchos posibles sistemas y aplicaciones. Podemos distinguir tipos de MassApp dependiendo de cuál es el recurso, el tipo de recurso que combinamos. Por ejemplo, si estamos combinando fuentes de información, datos, realmente eso es un MassApp de datos y un ejemplo típico el que viene, el más inspirador que viene a la cabeza cuando piensa uno en este tipo de MassApp, es Yahoo Pipes. Yahoo Pipes tiene una serie de fuentes de información, principalmente feeds de un tipo u otro y puedes combinarlas, puedes filtrarlas, puedes hacer una serie de operaciones con ellas y al final tienes otra fuente de información, estás mezclando estos recursos y realmente consigues crear algo nuevo. Los recursos están en internet y se puede crear una riqueza adicional de recursos. Una cosa interesante es que no es necesario ser programador para hacer un Yahoo Pipes. Es decir, la barrera de entrada a la creación de un MassApp de datos es mucho más baja que la barrera de entrada a tener que programar una aplicación que combine esos flujos y para el fin que se quiera. Con lo cual mucha más gente puede colaborar, estamos llegando más lejos en esa larga cola y como decía Eric Clemon acerca de los bugs, si hay suficientes ojos, cualquier bug puede ser resuelto, si hay suficientes personas trabajando en algo, las soluciones van a salir. El siguiente tipo de MassApp es cuando tenemos aplicaciones o trozos de aplicaciones y los combinamos a nivel de interfaz. Este es un nivel más elevado, es otro tipo de integración y finalmente podemos distinguir las MassApp de aplicaciones en lo que estamos combinando pequeñas aplicaciones. Un caso particular de esto es el MassApp de Gatchez, que es el caso de EasyWeb. Ahora veremos lo que es un Gatchez. También se pueden distinguir los MassApp por el uso a que están destinados. Por un lado estarían los MassApps de consumo, están dirigidos a usuarios finales. Un caso típico de esto sería por ejemplo Google IG, que permite crear una página de inicio personalizada combinando Gatchez de un repositorio, muchos de ellos han sido contribuidos por una comunidad. Con lo cual realmente puedes construir tu aplicación página de inicio y ajustar las tus necesidades. Estos MassApps pueden ser, el contenido puede ser generado por los usuarios o no. Por ejemplo en Google IG al principio el contenido inicial no fue generado por los usuarios, pero los primeros Gatchez fueron generados por el propio Google. Al principio era un MassApp de consumo, pero no tenía contenido generado por el usuario. Al alcanzar cierta masa crítica empezaron a recibir contribuciones. Luego también existen los Business MassApps, que es este concepto llevado a la empresa. Es decir, son típicamente herramientas mucho más caras o directamente de pago. Y están más centradas en poder realizar integración de las fontes de datos que típicamente se encuentran en los entornos empresariales de forma más fácil. Por ejemplo servicios web pesados, etc. Bueno, volviendo al tema de los MassApps de Gatchez, los Gatchez se supone que son pequeñas aplicaciones que son reutilizables y están centradas en el usuario. Concentrado en el usuario nos referimos a que tienen en mente las necesidades del usuario, que el usuario pueda comprender los que son y puede manejarlo directamente. Y también son frontends de servicios. Es decir, si tenemos un servicio web, por ejemplo, no necesariamente los servicios web basados en SOAP, una aplicación basada en las APIs de, por ejemplo, Doodle, tiene un API REST que permite crear encuestas, realizar votaciones, etc. Hay muchos otros recursos que ofrecen interfaces de servicio. Estas interfaces no son directamente utilizables por los usuarios, porque al ser la mayor parte de los usuarios agnósticos respecto a que es un servicio, no lo comprenden, no tienen esa característica técnica que permite pensar en estos términos, no son capaces de entenderlos. Un gadget no tiene que tener esa barrera, tiene que ser directamente reconocible por un usuario y realmente por detrás puede estar invocando estos servicios. Realmente le está dando un frontend, una cara a esos servicios. Bueno, estos gadgets pueden ser genéricos, como por ejemplo un post-it, una to-do list, o pueden ser masa-dock. Siempre y cuando sean lo suficientemente fáciles de crear. Por lo tanto, una plataforma de MassApp debe permitirte crear gadgets de una forma sencilla y simple para poder hacer posibles muchas más variedad de pequeños gadgets que permitan alcanzar muchas más aplicaciones y, de nuevo, alcanzar la larga cola hasta un grado mucho más amplio, llegando a las necesidades de mucha más gente. Bueno, estos gadgets deben de estar adaptados a problemas reales y la imagen de las piezas de Lego, bueno, no tenemos Lego, es algo similar, están ahí porque en el fondo tienen que ser las piezas que un usuario pueda construirse su entorno de trabajo y la solución a su problema. Bueno, algunos ejemplos de cómo podría ser un gadget, la to-do list que he citado antes, es una pequeña ventanita donde puedes introducir tareas pendientes, un visor de mapas. Este está basado en Google Maps, pero podrían quedarse gadgets para cualquier otro servicio que permita ser embebido. Lectores de feeds, este feed reader podría estar conectado a cualquier feed en internet, incluso a un MassApp de datos creado con Yahoo Pipes. Estos son algunos ejemplos, pero la lista es infinita y, de hecho, puesto que las necesidades de los usuarios o de los miembros de la comunidad pueden ser muy diversas, igual que existen portales para todo tipo de fines, pueden existir gadgets para todo tipo de fines por restringidos que puedan parecer y que realmente ni pensemos en ellos al crear una plataforma de este tipo. Otro punto interesante de este tipo de plataformas es que desde un punto de vista ya más empresarial, pueden ser vistos como una forma de aprovechar las arquitecturas orientadas a servicios. Es un tema del que hoy en día las empresas son muy conscientes y digamos que este tipo de arquitecturas están ahora en producción. De hecho, SOA como buzzword, como palabra para vender aplicaciones y productos ya ha pasado por esa fase del hype cycle, digamos que ya está en la fase de madurez. Bueno, uno de los principios de SOA es que las empresas deberían estructurar sus aplicaciones de forma que sean servicios independientes, que no tengan las dependencias entre ellos explícitas, es decir, si una compañía ofrece un servicio, ah, por ejemplo almacenamiento de imágenes, debe tener una API y debe ser independiente de otros servicios que tenga, y luego las aplicaciones finales que quieran hacer los combinarán de forma que si las necesidades de negocio cambian puedan fácilmente reconfigurarse. Sin embargo, cada vez que requieran adaptarse a estos cambios en el negocio, tendrán que realizar una nueva integración programando, lanzando un desarrollo pesado tradicional y en la práctica se ha demostrado que la integración es más difícil de lo que se esperaba debido, por ejemplo, las complejidades de la pila tecnológica de los web services basados en SOA. Y también, como decíamos antes, el usuario final ha sido olvidado. Es decir, estos servicios no son centrados en el usuario. Es decir, tú puedes tener perfectamente estructurado una arquitectura SOA, todos los servicios de una empresa, y realmente los usuarios finales, tanto internos como externos de la empresa, no les es indiferente. Si necesitan de repente cambiar una de las aplicaciones, van a tener que lanzar el proceso pesado, de tener que ponerse en contacto con el Departamento de Informática Interno, o llamar a una empresa externa, transferir los requisitos e intentar hacerlo bien. Eso es un problema tradicional en los desarrollos software. Y pasado un periodo de tiempo largo, van a tener otra vez la aplicación adaptada a sus necesidades. Pero este impas puede ser más grande de lo que se debería. Con lo cual, en la práctica, SOA es una buena idea, pero realmente necesitamos unos servicios que los servicios sean comprensibles por los usuarios, que los usuarios puedan tomar partido de ellos, combinarlos realmente en sus necesidades, que los puedan adaptar a sus necesidades, y que sean comprensibles, hackeables, que se ponen aquí, no sé cómo decirlo castellano. Bueno, por lo tanto, las características de EasyWeb para intentar cubrir este campo, son las típicas de cualquier plataforma de MassApp, como las que hemos visto antes, en las que tienes un catálogo de gadgets, los puedes añadir, los puedes colocar en la pantalla, tienes un proxy para poder invocar los servicios, puntuaciones, búsqueda en el catálogo, etc. Y realmente el resto de características más distintivas, lo que diferencian a EasyWeb de otras plataformas de MassApp, son la intercomunicación entre gadgets, que ahora veremos que esto es muy importante, porque es donde de verdad le damos juego a los usuarios que no son desarrolladores a resolver sus problemas, les damos el punto de flexibilidad que no tendrían de otra forma. También múltiples Workspaces, que eso es algo que no tienen todas las plataformas funcionando de la misma forma que EasyWeb, y que en cuanto a las capacidades de soportar una comunidad, tiene características más avanzadas que otras plataformas. No solo los típicos tags que tienen, que tiene, por ejemplo, iGoogle para... Bueno, realmente iGoogle tiene categorías, pero otras plataformas tienen tags, tanto para los gadgets como para MassApps completos. Realmente no solo se puede compartir un gadget en EasyWeb, también se puede compartir un MassApp completo, puesto que ahora veremos que un conjunto de gadgets interconectados puede ser la solución a un problema, tiene sentido poder compartir un MassApp completo. Y que otras personas lo puedan modificar, lo puedan también recomendar, etc. Y luego, finalmente, una característica importante, es que es fácil desarrollar gadgets para EasyWeb. Es decir, las APIs realmente tienen la mínima superficie de fricción posible, y son claras y sencillas de usar. Y también existen librerías, este es un aspecto en el que se está mejorando ahora mucho, librerías que permiten. En el lado del desarrollo del gadget, realizar tareas comunes como, por ejemplo, crear gadgets con tabs y otros elementos de interfaz un poco más avanzados, de forma muy simple. Bueno, y así comparando con otros proyectos, una de las principales ventajas de EasyWeb es su forma de licenciado. No estoy seguro de que sea la única, pero no he tenido noticia de que ninguna de las otras plataformas de MassApp está licenciada como un afero GPL, es decir, es completamente libre, no a poder ser cerrada en ningún momento, y eso es una garantía. Y como dijo el conferenciante anterior, si en algún momento se nos desviamos del camino, siempre podrá alguien hacer un fork y continuar con el proyecto por el buen sendero. Esto nos lleva a que existen mucha más libertad a la hora de usar esta plataforma que estas otras plataformas. Si necesitas tener una versión interna tu empresa de la plataforma de MassApp, porque por ejemplo, desde que la interfaz que tengan tus operadores, imaginemos una empresa que se dedique a dar soporte telefónico a sus clientes. Diferentes departamentos podrán configurarse de diferente forma su entorno, y realmente no quieres que sea compartido por el resto de otras empresas, o que puedan entrar. Realmente quieres tenerlo para dar tu servicio interno. Por ejemplo, en iGoogle no podrías realizar esto. Quizás con el paso del tiempo ofrezcan una versión privada, igual que con las Google Apps. Es posible utilizar Google Mail para una empresa, pero sigue sin tener la libertad de correrlo en tu propio hardware, de realizarle modificaciones, y siempre vas a tener que firmar unos términos de servicio que a mí siempre me han asustado mucho, porque son generalmente dos metros de scroll. Realmente es imposible comprender lo que pone sin ser un abogado, y es algo que la gente firma sin pensar en ello. Otras propiedades, bueno, insisto de nuevo en la comunicación entre gadgets, y bueno, otra cosa interesante, es que iSiWeb está basado en estándares libres completamente. Por ejemplo, Microsoft PubFly está basado en Silverlight, y aunque haya algunas alternativas, plantea algunos problemas morales desde el punto de vista de las licencias de todo el stack de tecnologías. Bueno, ¿qué plataforma soporta iSiWeb? iSiWeb está basado en Python, y en teoría es posible instalarlo en cualquier sitio que está un intérprete de Python. ¿Dónde es más sencillo instalarlo? Entre otros sitios, en Debian y Nubuntu, puesto que tenemos un empaquetado en Dev. Desafortunadamente no está incluido en la distribución, estamos intentando reclutar a algún Debian developer que nos esponsore la subida del paquete, y no tenemos prisa porque de momento nuestros paquetes todavía no cumplen la Debian policy, ¿sí? Sponsor. Tenemos debian packages, debian packages, no están en la distribución oficial, pero estamos trabajando en improvisar a ellos y permitiendo, porque no queremos decir que tenemos debian packages, pero tienen algunas de las debian policies. Tenemos Trilintian y se explotan algo completamente malo. Yo lo puedo escuchar. ¿Lo necesitas? ¿Tienes alguien para ver estos paquetes? No, tenemos que uploadar a la distribución. Tenemos un poco de consejos, pero podemos hacer las cosas básicas. Tenemos debian, tenemos un entendimiento, despite running macros x, estoy usando debian a mi estación de trabajo y así. Usamos, por ejemplo, en la UPM, en el lugar donde trabajo, muchas de las maestras están usando debian, y a veces, tenemos debian packages a algunos proyectos, y estamos en la filosofía de Debian, pero no somos debian developers. Ok, aquí es el lugar correcto para encontrar una buena persona para ver tus paquetes y tenerlos uploadados. Eso fue mi punto de vista, gracias. Pero no solo eso, estamos buscando para introducir esta plataforma, por ejemplo, si necesitas integrar diferentes source de información, por ejemplo, hay un proyecto de Debian para unir todas las documentaciones sobre el proyecto y las experiencias. Eso es exactamente el nombre, pero tal vez, podemos ofrecer su apoyo para usar la web Easy para ese propósito, y eso sería bien. Ok, estoy intentando ahora el URL que tienes en los slides, y creo que es malo. No llegaré a europa.fi.upm.es. ¿Puede ser Europa en vez de Europa? No lo sé. Tal vez. ¿Puede ser Europa? Sí. Pero, me voy a revisar más tarde. Pero este es el URL de la repositoria. Puedes poner DEV y HTTP. No sé si continuo en inglés o en español o cualquier cosa. Bueno, ya no. ¿Dónde lo dejé? Lo siento. Bien. Estamos trabajando en las políticas de Debian para estos paquetes. Bueno, de hecho, también tenemos algunos bugs en los paquetes. Dependiendo de qué paquetes instale primero, a veces revienta. En fin. Estamos trabajando en ello. Bueno, y también estamos ahora mismo, pero con... Está un poco más verde. Paquetes para Red Hat y un instalador basado en MSI para Windows. Pero bueno, por supuesto tiene menos prioridad. Bueno, y en cuanto a los navegadores soportados, EasyWeb funciona perfectamente en Firefox, en Chrome, Safari y Opera. Y tenemos algunos problemas con algunas versiones de Internet Explorer. Debido a que están tan diferentes. Bueno, los problemas que tiene con esto que llamamos estándares. Bueno, el roadmap de características que se van a desarrollar durante los próximos meses pasa por... Estamos ahora en un esfuerzo de soportar más navegadores. Por ejemplo, Internet Explorer. Iremos directamente a por el 7. Y algunas otras mejoras. Por ejemplo, el proxy. Bueno, esto es algo de lo que no he hablado hasta ahora. Pero existe un problema grande en el mundo de los más apps de usuario. Y es el cross-site scripting. Los navegadores, por motivos de seguridad restringen las direcciones a las que JavaScript puede conectarse por Ajax para realizar peticiones. El mismo dominio del que se ha descargado el propio script. Evidentemente, si yo creo un gadget para, por ejemplo, listar mis fotografías, las 10 últimas fotografías que he subido a Flickr, a mi cuenta de Flickr, esta propiedad no se va a cumplir. Porque yo este gadget lo voy a alojar, por ejemplo, a mi servidor personal. Y va a intentar invocar a la API de Flickr. Entonces, las plataformas de MassApp, para poder sobrepasar este problema, tienen... implementan un proxy que permite realizar esta llamada a través del servidor de la plataforma de MassApp. Estos proxies están ahora evolucionando al igual que las características de los navegadores. Y hay algunas mejoras que se van a realizar. Por ejemplo, la próxima generación de navegadores va a incluir, algunos, por ejemplo, Firefox la posibilidad de hacer cross-site scripting de forma segura utilizando extensiones, ciertas cabeceras, para permitir que si se puedan realizar esas llamadas AJAX a unos servidores autorizados. Bien, eso es mucho más eficiente que realizarlo a través del proxy de la plataforma. Una de las mejoras que se realizarán al proxy de EasyWeb es detectar cuando el navegador del cliente permite esta característica y hacer que la llamada se realice a través del navegador sin utilizar ese proxy de forma selectiva. Otras mejoras van a ser la mejora de la experiencia de usuario al tratar más tipo de excepciones, más posibles fallos y mensajes de error, de status messages de HTTP y más opciones que permitan manejar mejores las situaciones y proporcionar una respuesta mejor. También se quieren añadir esta transparencia está mal, esto debería ser un punto de primer orden añadir más características semánticas al catálogo de Gatsch y de MassApp, permitiendo una búsqueda más inteligente y más adaptada al usuario. Es decir, que realmente puedes decir caracterizar semánticamente cuál es el propósito del Gatsch. Si tienes un Gatsch que sea un visor de imágenes tendrás que poder hacer referencia a cierto concepto, de cierta ontología que te esté describiendo que eso sirve para mostrar imágenes. Si tienes un autor para ese Gatsch tendrás que poder utilizar por ejemplo la ontología FOA para describir que el autor de ese Gatsch funciona y está unido a tal proyecto etcétera. Y también la implementación o soporte de APIs que están ahora en fase de estandarización como OpenIAC y OpenSocial que permitan que los gadgets que se porten a ICWeb o que se desarrollen para ICWeb sean fácilmente portados a otras plataformas que sean más fácil que sean incluidos. Por ejemplo, hay algunos proyectos que permiten desarrollar un gadget una sola vez y que sea desplegado en distintas plataformas. Por ejemplo, en Facebook en iGoogle y en ICWeb al mismo tiempo. Si todas estas plataformas implementas en OpenSocial esta tarea sería mucho más trivial y por lo tanto es un buen paso a dar. Además, al reducirse el número de interfaces que un desarrollador web tenga que aprender podrá ser más productivo. Y un punto un poco negro en el roadmap es el tema de la seguridad. Como decía antes los navegadores en Restringen que llamadas se pueden realizar a otros dominios y es por un buen motivo porque realmente si no cualquier gadget podría tomar el control del resto de cuentas a las que accedan el resto de gadgets y secuestrar tu sesión de Gmail a partir de ahí conseguir tu contraseña en el resto de sitios tu número de tarjeta de crédito y básicamente alguien podría reemplazarte o algo peor. Pero bueno, no es tan grave. Creía que tenía otras transferencias sobre la seguridad. Bueno, este es un problema universal y puede que se solucione la evolución de HTML y de los navegadores. Con mejores a la etiqueta Object se podría conseguir una separación más eficiente entre los distintos códigos que se carguen en el MassApp y tiene pinta de ir a mejorar en el futuro. ¿Qué se puede hacer por el momento? Pues no utilizar cuentas críticas en el mismo MassApp como cuentas normales que las APIs a las que accedamos no sean críticas y hay otras soluciones como, por ejemplo, firmar los gadgets eso es algo que se puede implementar es decir, si podemos confiar en todos los gadgets que están envueltos en el MassApp no hay ningún problema y está el entorno de los entornos separados. Si, por ejemplo, queremos utilizar la intranet de una empresa y que cada trabajador tenga su entorno personalizado no existe ningún problema puesto en el catálogo de gadgets, sólo van a estar los que nosotros inicialmente pongamos más los que los propios usuarios creen ellos mismos y como en teoría se puede confiar en la propia comunidad no existiría ningún problema pero este es el punto más negro y es un punto pendiente y que ninguna plataforma de MassApp hasta donde sea ha solucionado pero bueno es también un campo de investigación la arquitectura DCWeb este diagrama es un poco complicado pero intentaremos explicar un poco cómo funciona realmente tenemos una parte en el navegador del cliente una parte en el servidor tenemos recursos que están dispersos por internet y que están aquí agrupados realmente da igual que tecnología utilizan para acceder a los datos del backend esto es externo ICWeb y es tan diverso como el propio internet y estos son los recursos que los gadgets van a utilizar para ofrecer su funcionalidad entonces esta interacción de aquí aparece con línea discontinua que realmente por el cross-site scripting no se puede realizar la interacción de estos gadgets con los servicios se realizaría a través del proxy siguiendo este tortuoso camino a no ser que las próximas generaciones de navegadores no simplemente en este cross-site scripting seguro bueno y que tenemos realmente tenemos un catálogo de gadgets estos gadgets están dispersos por internet aunque la propia plataforma ICWeb puede albergar gadgets físicamente pero realmente cada usuario en internet podría tener su propio servidor con su propio conjunto de gadgets y ofrecérselos a todo el resto de internet simplemente tendría que registrarlo en el catálogo de ICWeb y los usuarios finales podrán encontrar estos gadgets o los encontrarán como parte de un mashup este mashup se ejecutará en el navegador donde ICWeb provee cierta infraestructura a los gadgets y se realiza la visualización final bien, este pequeño documento que aparece aquí junto al gadget es una pieza de metainformación es un documento XML que cada gadget debe hacer público esta metainformación que se llama template es un nombre un poco desafortunado porque realmente no es un template, es más bien metadata pero fue el nombre que se le dio inicialmente y es el nombre que persiste hasta el momento es lo único que se necesita para poder poner un funcionamiento incluye información como cuál es el autor relativa a la interfaz con otros gadgets para poder realizar su integración su interconexión y otros aspectos de un poco más bajo nivel bueno, el stack de tecnologías que soporta esta arquitectura es para empezar el modelo vista controlador que proporciona Django la plataforma está hecha en python todas las interfaces que se ofrecen son RESTful HTTP que con representaciones basadas en JSON que es una forma muy muy apropiada para que se pueda hackear y jugar con las propias interfaces por supuesto el cliente está basado en Javascript el único framework que se utiliza es prototype y en teoría los gadgets pueden utilizar el prototype que viene con la plataforma o incluir cualquier otro framework que no sea incompatible con prototype por ese motivo no hemos introducido más frameworks aunque a veces nos hemos visto tentados bueno la persistencia que se realiza para la comunicación entre los datos entre el cliente y el servidor es una caché con política de escritura cada vez que se realiza una modificación eso tiene sus ventajas, algún inconveniente en alguna situación concreta de escalabilidad pero en general funciona bastante bien y permite extender la funcionalidad hasta el momento no hemos tenido problemas bueno en cuanto a las tecnologías de backend, de los servicios que se vayan a utilizar por los mass apps realmente es indiferente siempre y cuando le ofrezca una interfaz HTTP probablemente basada en json o en xml que lo más apropiado es formatos sencillos que sean fáciles de tratar desde javascript y finalmente los gadgets realmente pueden ser escritos en cualquier tecnología lo único que se necesita es que se les pueda apuntar con una url que sea cualquier contenido que podamos meter en un iframe o en un object y si se van a utilizar las características de intercomunicación entre gadgets es necesario que la aplicación utilice un poquito de javascript aunque realmente dentro de un html podemos enviver lo que queramos podríamos meter flash incluso silver light o directamente javascript o cualquier otra tecnología que surja en el futuro simplemente introduciéndola en el documento hablando del gadgets template es un documento xml tiene un enlace a la implementación del gadgets y define la interfaz del gadgets en función de lo que se ha llamado variables estas variables pueden ser distintos tipos y aquí viene la parte interesante los slots empecemos por lo más fácil los settings son directamente propiedades que se puedan guardar con las preferencias del usuario hay ciertas variables que son información del contexto datos útiles sobre la plataforma sobre el usuario que permitan adaptar el gadgets por ejemplo el idioma que ha seleccionado el usuario y son algo parecidos a los settings pero sin que los tenga que ver el usuario puede servir para guardar una pequeña información para continuar la ejecución del gadgets en la siguiente vez que se invoque y lo realmente interesante son los slots y los eventos un gadget define slots para poder recibir eventos externos provenientes de otros gadgets o de la propia plataforma estos slots pueden estar basados en una pequeña estructura de datos o simplemente un evento que permite realizar construcciones en las que por ejemplo un gadget genérico para visualizar imágenes reciba URLs de imágenes de otros gadgets por ejemplo podemos tener un gadget cliente de correo que al cargar una imagen con adjuntos que sean imágenes provea de un evento que es el otro tipo de propiedad que como salida de estas URLs con lo cual podemos tener que automáticamente ver nuestros emails veamos las imágenes o podemos hacer una búsqueda en Flickr y que esa URL sea pasada la imagen o cosas más elaboradas como por ejemplo el gadget que vimos antes de mapas de Google Maps puede recibir una dirección esa dirección puede provenir de una petición de asistencia técnica de las posibilidades la API de EasyWeb está basada en forma de un objeto EasyWeb API y tiene dos grupos de métodos principales para inicializar estas variables que hemos visto antes por ejemplo esta sería una variable de solo lectura podríamos utilizarla para recibir eventos y luego otras para los cuatro verbos de HTTP y hacer uso del proxy bueno y realmente ya no tengo más transparencias me habría gustado hacer una pequeña demo de cómo queda esto en funcionamiento voy a enseñaros rápidamente cómo podría lucir la plataforma esto es un MassApp que podéis encontrar en EasyWeb.tis.es este es el que viene preconfigurado podéis jugar con el y realmente aquí hay un poco de todo tenemos una serie de gadgets y por ejemplo este de Flickr hablando acerca del ejemplo que decía antes de las imágenes esto es una búsqueda genérica si pulsamos en cualquiera de ellas vamos a este otro tab como el visor de imágenes tenemos otro gadget que es diferente de la anterior en el que podemos hacer una búsqueda por ejemplo Caceres y obtendremos imágenes no muy relacionadas bueno esta si parece con lo cual acabamos de utilizar este gadget con de dos formas distintas es decir cada usuario puede utilizar este gadget estos son gadgets genéricos para una aplicación concreta tendrías que buscar el conjunto de gadgets genéricos que pudiesen servirte y quizás pensar en desarrollar o encontrar a alguien que te haga algún gadget específico y de esa forma mucho más rápido puedes crear aplicaciones y modificarlas en cualquier momento puedo mover cualquiera de estos puedo eliminar alguno puedo añadir gadgets este es el catálogo del que hablaba antes bueno, esto de aquí es un masap completo que podemos cargar bueno y la parte en la que se realiza la conexión de los gadgets es esta otra pantalla donde en esta columna tenemos todos los eventos de los gadgets en esta otra tenemos todos los slots de los gadgets el gadget de flicker acepta este es el de búsqueda acepta keyword que pueden provenir de cualquier otro gadget y tiene como salida la url de la imagen que haya sido seleccionada de esta forma se pueden combinar y estos canales son los que permiten la interconexión esto lo puede realizar un usuario que no tenga conocimientos de programación con lo cual estamos yendo a por ese aprovechamiento de mayor parte de la comunidad y en teoría cuantas más personas están pensando en un problema más rápido y más adaptado a las necesidades además si con la base de gadgets existente en un momento dado es suficiente para conseguir una solución a un problema no necesitaremos esperar a que alguien nos lo haga y si en caso de necesitar un gadget específico es mucho más fácil que desarrollar una aplicación completa y supongo que ya he consumido los 5 minutos extra que me quedaban así que no sé si queda algo de tiempo para alguna pregunta me habría gustado componer algún masap desde cero para que veáis si es todo el proceso pero no hay tiempo alguna pregunta any question