=== Tracker en GNOME === ''' Expositor: Iván Frade (frade) ''' ''' Moderador: Sergio Infante (neosergio) ''' '' Sábado 05 de septiembre de 2009, 17:00 horas UTC '' '' irc.gnome.org #gnome-hispano '' ---- neosergio {{{ Buenas tardes, siendo las 17 horas UTC, damos inicio a la charla IRC de setiembre de Gnome Hispano }}} neosergio {{{ El dia de hoy tendremos el honor de atender a la charla de Ivan Frade que nos dara alcances sobre Tracker }}} neosergio {{{ Unos datos sobre el Ivan Frade es desarrollador de tracker y trabaja en nokia integrándolo en la plataforma Maemo (distribución basada en linux usada en los Internet tablets). Es además contribuidor en otros proyectos de la plataforma gnome y ha participado en distintos eventos de la comunidad. Ultimamente se dedica a hacer promoción de tracker en todo foro a su alcance para integrar mas aplicaciones y atraer contribuidores a la (fantasiosa) idea de un desktop con metadatos centralizados. }}} neosergio {{{ bueno entonces con ustedes Frade :D }}} '''frade''' {{{ gracias neosergio muchas gracias a todos los que estais ahí leyendo esta es mi primera charla en el IRC, espero que salga bien como neosergio explicó antes, mandadle a el en privado la preguntas para mantener el canal organizado podeis mandarle las preguntas en cualquier momento, y mejor que interrumpais para hacer la charla mas amena y mas en forma de dialogo }}} '''frade''' {{{ mi plan es explicar brevemente como empezó tracker y que era tracker hasta la version 0.6 la que la mayoria de vosotros, usando las distribuciones habituales, tendreis instalada pero sobre todo lo interesante es el futuro tracker 0.7 donde proponemos una idea completamente distinta y mucho mas interesante para el escritorio en general }}} '''frade''' {{{ = Tracker hasta 0.6.6 = }}} '''frade''' {{{ Tracker empezó como una alternativa ligera y en C a Beagle Beagle es un buscador en C# (disponible en muchas distribuciones) que (al menos al principio) consumia mucha memoria, asi que Jamie McCracken decidió empezar tracker ambos proyectos tenian la misma idea: escanear el disco duro (la parte del usuario) leer la informacion y meterla en un indice de tal manera que se pudiese buscar rapido }}} '''frade''' {{{ tambien se dieron cuenta de que "archivos" en general, es muy vago y normalmente el usuario sabe que _tipo_ de archivos busca asi que añadieron categorias, como Musica, Video.... para refinar la busqueda e incluso empezaron a extraer informacion de los ficheros (como el ID3 de los mp3) Tracker incluso empezó (no estoy seguro de Beagle) a soportar "tags" etiquetas es decir, el usuario puede asignar una palabra(s) a un determinado fichero para encontrarlo despues hasta aqui no hay muchas sorpresas, y es la idea normal de un buscador }}} '''frade''' {{{ = Tracker 0.6 -> 0.6.96 = }}} '''frade''' {{{ Hace mas o menos 1 año y media, en nokia pensamos en añadir un sitio centralizado para datos y metadatos en maemo (maemo es la distribucion de linux que nokia usa en sus "internet tablets", y ahora en un telefono) tracker era la decision obvia: ligero, escrito en C... usando los estandares de freedesktop... y compilaba casi directamente en maemo }}} '''frade''' {{{ sin embargo resultada muy dificil de ampliar o mejorar el codigo habia ido creciendo y creciendo y nadie habia puesto un poco de orden asi que habia codigo duplicado, no habia modulos claramente separados... asi que con la ayuda de algunos bravos hackers (incluido garnacho, presente en este canal) empezamos a limpiar y reorganizar el codigo }}} '''frade''' {{{ fue un proceso largo, que nos llevó a la version 0.6.90 y siguientes (que son las incluidas hoy en dia en las distribuciones) esta version 0.6.9x es tambien la incluida en maemo5, el ultimo release de maemo que es el software que corre en el N900, anunciado por nokia esta semana la pregunta entonces es.... "esta tracker terminado?" o quiza... "que le falta a tracker?" despues de un año trabajando en el, nos dimos cuenta de muchas limitaciones no solo en el codigo, sino en todo el concepto de "buscador" }}} '''frade''' {{{ soportamos etiquetas, pero no podemos guardar metadatos mas complejos por ejemplo, una direccion que contiene varios campos y tracker esta pensado para indexar el sistema de archivos asi que no podemos guardar en tracker nada que no tenga forma de archivo es decir, no podemos guardar contactos e incluso, si haciendo "trampas" guardasemos contactos, no podemos enlazar un contacto con un archivo o hacer cosas mas interesantes }}} '''frade''' {{{ tracker 0.6 esta bien para ser un indexador, pero necesitamos algo mas necesitamos decir más cosas sobre más recursos (paginas web o contactos, por poner un ejemplo) y necesitamos unir esa informacion entre si, para poder ofrecerle algo más al usuario Asi que después de darle muchas vueltas, llegamos a la idea de tracker 0.7 }}} '''frade''' {{{ (alguna pregunta hasta ahora?) }}} neosergio {{{ me parece que todo claro }}} '''frade''' {{{ bien }}} neosergio {{{ no ha llegado preguntas aun }}} '''frade''' {{{ == tracker 0.7 == }}} '''frade''' {{{ esta es la parte interesante En tracker queremos guardar informacion sobre "cosas" (ficheros, paginas web, contactos, bookmarks)... y enlazar esa informacion entre si "mi amigo X me mandó el fichero Y" "esta foto Z la publiqué en facebook y se la mande por correo a A,B y C" }}} '''frade''' {{{ y esto abre varias preguntas: 1) Para qué guardar esa informacion 2) Como representarla/almacenarla para consultarla de forma eficiente 3) Como reunir esos datos }}} '''frade''' {{{ El punto 1) es uno de los que mas nos cuesta explicar la idea que tenemos en tracker, es olvidarnos de "la busqueda de texto" olvidarnos de "el usuario teclea y nosotros *magicamente* le damos lo que busca" el camino de "la busqueda libre de texto" esta muy explorado y los resultados no pueden ser buenos pueden parecer mas o menos buenos, pero no se puede hacer nada interesante }}} '''frade''' {{{ sin embargo, al tener la informacion "relacionada" las aplicaciones pueden mostrar "contexto" al usuario el navegador puede mostrar un bookmark, y la informacion del contacto que me lo mandó en la aplicacion de mensajeria, puede ver al contacto y los bookmarks que me envió, o los ficheros, o los mp3... lo importante es qeu no es el usuario el cliente de tracker sino _las aplicaciones_ }}} '''frade''' {{{ eso nos lleva al punto 2) la aplicacion quiere usar esa informacion... como la vamos a guardar y consultar? para eso vamos a usar un par de ingredientes de la "web semantica" una cosa llamada "RDF" (tripletas) y un lenguaje de consulta llamado "SparQL" para darle sentido a las tripletas, usaremos un tercer ingrediente, llamado "ontologia" }}} '''frade''' {{{ antes de descifrar esas palabras, voy a por el punto 3 para resolver el problema de reunir la informacion, vamos a cambiar la arquitectura de tracker y como las aplicaciones interactuan con el en lugar de tener un indexador que recorre el disco duro interpretando los ficheros de los otros programas tracker va a ser un almacen de informacion, pasivo, con un esquema bien definido y las aplicaciones meteran la informacion directamente en tracker }}} '''frade''' {{{ algunas aplicaciones tendran UI (por ejemplo Tomboy guardando sus notas en tracker) otras seran solo procesos (uno monitorizando twitter, bajando los ultimos mensajes y guardandolos de nuevo en tracker) }}} '''frade''' {{{ el ejemplo de Tomboy me gusta especialmente: _antes_ tracker iba al directorio .tomboy, leia los ficheros, los parseaba para entender la informacion y la guardaba el problema mas evidente: que pasa si tomboy cambia su formato _ahora_ (0.7) tomboy tendra un plugin que escribira sus notas directamente en tracker, en un formato bien definido es mas, al estar el formato bien definido cualquier otro programa puede preguntar "dame todas las notas" o "dame todas las notas entre esta fecha y esta otra" o, incluso si tenemos informacion de GPS disponible y al guardar la nota alguien añadio "salvada en Gran Canaria el 7 de Julio de 2009" un programa podria mostrar un mapa con las notas en las localizaciones (y ese programa seria independiente de Tomboy en si mismo) las notas podrian venir de distintos programas. en el momento que son traducidas a nuestro "esquema predefinido" son pura informacion, independiente del programa }}} neosergio {{{ frade una pregunta }}} '''frade''' {{{ (y accesible para todos los demas programas) }}} '''frade''' {{{ neosergio, si }}} neosergio {{{ pregunta de eeejza : que differencia tiene estos metadatos con los posibles metaadatos de sistema como atributos extendidos (chattr) que te da un filesystem moderno. y Tracker es similar a lo de KDE con nepomuk? }}} '''frade''' {{{ los atributos extendidos estan metidos en el sistema de ficheros y son mucho mas limitados de lo que podemos almacenar en tracker son metadatos tambien (y de hecho es informacion que siempre leemos de los ficheros) pero no es tan flexible como una base de datos "externa" a su favor tienen que siempre serán mucho mas eficientes la idea de tracker va por informacion mas de "alto nivel" (al menos mi idea de esos atributos extendidos es que guardan informacion mucho mas tecnica, no en el nivel del usuario) de todas formas, son soluciones complementarias cierta informacion ira en los atributos extendidos, otra en tracker (con esto espero haber aclarado la primera pregunta) }}} '''frade''' {{{ Nepomuk era un proyecto europeo, que produjo varias cosas una de ellas son las ontologias, (el "esquema predefinido") que queremos usar en tracker eso significa que KDE y GNOME hablaran el mismo vocabulario para almacenar la informacion estamos en contacto con la gente de KDE, y tenemos planes para compartir mas y mas cosas (la primera tarea es hacer un paquete de ontologias, un "shared-desktop-ontologies".... igual qeu compartimos la base de datos de mimetypes) espero que esto aclare la segunda pregunta }}} neosergio {{{ frade, hay dos preguntas mas }}} '''frade''' {{{ genial! }}} neosergio {{{ la primera pregunta de _acs_ : pregunta: ¿no será complicado modificar todas las aplicaciones para que guarden su información según las ontologías de Tracker? }}} '''frade''' {{{ buena pregunta es mucho trabajo, si pero no hay que hacerlo de un solo golpe las aplicaciones iran implementando plugins para meter informacion en tracker para las mejor diseñadas sera trivial, otras tendran que modificar bastante el codigo (yo lo veo hasta una forma positiva de probar/mejorar el diseño de las aplicaciones) la complicacion no es el codigo de la aplicacion en si sino que las ontologias (de nuevo, el esquema comun que proponemos) contenga todo lo que necesitan en ese sentido en maemo hacemos de punta de lanza, y estamos recibiendo mejoras y comentarios de aplicaciones en varios dominios en el mundo GNOME, sin demasiadas complicaciones, es facil "enchufar" telepathy (IM) a tracker, para evolution hay un plugin... de momento es bastante "hackerish" pero en el futuro, cuando la cosa se asiente, y tengamos una buena documentacion, y proyectos haciendo masa critica esas adaptaciones seran mucho mas sencillas }}} neosergio {{{ la siguiente pregunta, podria ayudar aun mas para tener mayor claridad del panorama pregunta de _acs_ : ¿es escalable lo que propone Tracker de centralizar toda la información del escritorios? }}} '''frade''' {{{ Tenemos un modelo de base de datos que "escala" muy bien y no se centraliza _TODA_ la informacion del escritorio sino la informacion "de usuario" es importante aclarar que tracker ofrece un almacen para la informacion a) de usuario b) relevante para el desktop tracker NO es el reemplazo de SQLite para las aplicaciones es totalmente licito (y recomendable) que las aplicaciones tengan sus propias bases de datos para sus cosas volviendo a la eficiencia, en tracker algunas pruebas con 5000 contactos, sus telefonos y direcciones postales las respuestas a las consultas (nombre para este numero de telefono, etc...) llegan en unos pocos milisegundos y eso sin haber entrado en optimizaciones "profundas" }}} '''frade''' {{{ neosergio, alguna pregunta mas? }}} neosergio {{{ una mas pregunta de eeejza : si tracker guardaba la info en .tomboy quiere decir que tomboy era una dependencia de tracker? Sabes si tracker lee las dublin:core (metadatos) de OpenDocuments? }}} '''frade''' {{{ uhmmm no, la relacion tracker/tomboy es en la otra direccion tracker _leia_ la informacion de tomboy (tomboy no sabia nada de tracker) en el futuro, tomboy deberia escribir sus notas en tracker, y entonces la dependencia es: tomboy depende de tracker (estamos proponiendo tracker como modulo en la plataforma GNOME para facilitar esta dependencia de las aplicaciones) sobre los OpenDocuments, no estoy seguro si no recuerdo mal tracker indexaba los ficheros de openoffice y office usando programas externos (w3... o algo asi) en un futuro, si las cosas van bien, usaremos libstreamanalyzer (del proyecto strigi) para leer ficheros en cualquier caso: si no lo hacemos todavia, sin duda son metadatos qeu esperamos extraer de los ficheros }}} '''frade''' {{{ nos quedan 5 minutos... verdad? }}} '''frade''' {{{ mi plan era mas o menos: contar que son las tripletas/RDF/ontologias, un ejemplo del lenguaje de consulta y algunas ideas de como veo Tracker y GNOME3 }}} neosergio {{{ excelente }}} '''frade''' {{{ bien }}} neosergio {{{ nadie mando mensajes quejandose de la extension de la charla, entonces adelante }}} '''frade''' {{{ como antes cité, vamos a guardar la informacion usando algunos ingredientes de la web semantica el mas importante de ellos posiblemente sea "RDF" es un estandar del W3C, teneis una especificacion online http://www.w3.org/TR/REC-rdf-syntax/ y este documento que acabo de poner el link (RDF Primer) es una buena introduccion (en ingles, eso si) }}} '''frade''' {{{ lo que yo quiero contar es una version hiperresumida la idea de RDF, es que todo lo que necesitamos decir sobre algo, se puede expresar en tripletas en un grupo de tres elementos: }}} '''frade''' {{{ algo asi como en el lenguaje natural: sujeto, verbo, predicado así, si hablamos de "http://maemo.nokia.com", podemos decir autor "nokia" habla-de "maemo" el sujeto es el elemento del que hablamos (en este caso una pagina web, podria ser un fichero, o incluso una URL sin significado real) las propiedades en este caso son "autor", o "habla-de" }}} '''frade''' {{{ ops, perdon por la errata donde antes dije frade> queria decir frade> frade> }}} '''frade''' {{{ el objecto, en los ejemplos qeu acabo de poner, es solo una cadena de caracteres puede ser un numero, como cuando digo numero-reproducciones 15 y sobre todo.... el objeto puede ser otra URI, otra referencia a un objecto contiene-video fijaros que si le damos una URL a nuestros contactos otra a los ficheros (ya la tenemos, los famosos file://...) otra a los recursos online (http://...) con tripletas podemos relacionarlos con tripletas tambien se pueden definir "clases" o "conceptos" }}} '''frade''' {{{ Contacto es-un Concepto nombre es-un Propiedad y asi puedo decir que es-un Contacto si pintamos las URL como "nodos" y las propiedades como arcos que unen esos nodos -> tenemos un grafo un grafo se puede convertir en tripletas y al reves (son equivalentes) }}} '''frade''' {{{ esta idea (creo qeu sencilla) es realmente RDF el siguiente paso es entonces "que propiedades puedo usar?" "que categorias existen?" si una aplicacion usa la propiedad "nombre" y otra "contacto-nombre", no se entenderan es entonces cuando aparecen las famosas "ontologias" una ontologia nos dice qué clases/categorias podemos usar que propiedades }}} neosergio {{{ una pregunta }}} '''frade''' {{{ y la relacion entre todas ellas }}} '''frade''' {{{ si }}} neosergio {{{ pregunta de cal : que ontologias se estan usando con tracker / cuales se pretende empezar a utilizar? }}} '''frade''' {{{ tracker 0.6 usa una ontologia propia, muy sencilla y muy limitada tracker 0.7 va a utilizar las ontologias Nepomuk, con muchas modificaciones qeu estamos intentando incluir en la especificacion las ontologias nepomuk al menos las oficiales esta aqui http://www.semanticdesktop.org/ontologies/nie/ y las que tracker esta usando ahora mismo, tienes que leerlas de nuestro repositorio, aqui: http://git.gnome.org/cgit/tracker/tree/data/ontologies estamos discutiendo algunas mejoras en el proyecto XESAM con los mantenedores de las ontologias }}} '''frade''' {{{ continuo? }}} '''frade''' {{{ el lenguage de consultas que vamos a usar en tracker es SparQL es el estandard ahora mismo en el mundo de la web semantica recuerda lejanamente a SQL, pero esta diseñado para preguntar sobre tripletas }}} '''frade''' {{{ (para los mas avezados en el tema, en tracker soportamos el SparQL basico [consultas] y las extensiones para actualizar y borrar informacion) aqui la spec de sparql, por si alguien se aburre: http://www.w3.org/TR/rdf-sparql-query/ y aqui la propuesta de UPDATE: http://jena.hpl.hp.com/~afs/SPARQL-Update.html si entendeis las tripletas, sparql es casi directo }}} '''frade''' {{{ aqui va una consulta de ejemplo: SELECT ?u WHERE { ?u a nie:InformationElement. } }}} '''frade''' {{{ lo que le decimos es "dame todos los values de ?u" (lo que empieza con un signo de interrogacion es una variable) que encajen en ese esquema esto buscara en la lista de tripletas y nos dara todos los valores de ?u que sean validos }}} '''frade''' {{{ si tenemos en algun sitio a nie:InformationElement. a nie:InformationElement. el resultado de la consulta será y }}} '''frade''' {{{ este patron puede hacerse mas complicado: SELECT ?u WHERE { ?u a nco:Contact ; ?u nco:fullname "Ivan Frade". } en este caso los valores de "?u" tienen que cumplir con _las dos condiciones_ }}} neosergio {{{ antes de continuar otra pregunta }}} '''frade''' {{{ si }}} neosergio {{{ pregunta de gpoo pregunta: Al utilizar URL's como , se tiene la información de a.mp3 en ese directorio. Pero si muevo ese archivo a otro directorio, me quedará "basura" en tracker ¿cómo se limpia el contenido en tracker? la pregunta se relaciona a que programas como Banshee no se dan cuenta de ello, y si no se dan cuenta, mal podrían notificar a tracker }}} '''frade''' {{{ si la solucion que tenemos en tracker, es un poco mas complicada usaremos una uri generada para el "contenido" y enlazaremos con la uri "de la localizacion" mejor con un ejemplo en tracker ese mp3 sera: a nmm:MusicPiece. nmm:duration 1000. # pon aqui mas propiedades del mp3 nie:isStoredAs . de tal manera qeu al mover el fichero esta ultima URL cambiara pero para banshee la URI del fichero es la misma es mas, si hay dos copias del fichero y somos capaces de detectarlo podemos ponerle dos nie:isStoredAs al mp3 y banshee solo verá uno (pero esto tiene otros inconvenientes... es un tema en el que estamos trabajando) }}} '''frade''' {{{ bien, volviendo al lenguage de consulta un detalle mas es que las variables pueden ir tambien en el lado del "objeto" de la tripleta podemos hacer: SELECT ?name WHERE { nco:fullname ?name. } eso nos devolvera el valor de ?name que encaja con esa tripleta }}} '''frade''' {{{ y finalmente, podemos concatenar variables SELECT ?name ?codigoPostal WHERE { ?u nco:fullname ?name. ?u nco:PostalAddress ?x . ?x nco:postalCode ?codigoPostal. } (perdon por el spaglish en las consultas) en resumen: tripletas/grafo es un esquema adecuado para representar informacion y relacionarla entre si y SparQL es un lenguaje de consulta sencillo que se mapea directamente en tripletas, para consultar esa informacion }}} '''frade''' {{{ la instalacion de tracker 0.7 ahora mismo es solo recomendada para desarrolladores pero si alquien se anima a instalarlo (desde el repositorio) las consultas SparQL estan funcionando e incluso devuelven resultados despues de indexar los directorios del usuario no voy a entrar mas en detalle sobre RDF/Sparql si teneis alguna pregunta sobre esta parte... }}} neosergio {{{ pregunta pregunta de cal: tracker-sparql solo esta disponible en la version de desarrollo? *no lo encuentro en la 0.6.95-2/debian sid* }}} '''frade''' {{{ si tracker-sparql es una herramienta nueva en tracker 0.7 tracker 0.6 no soporta Sparql de hecho, usa un RDF muy muy muy reducido para las consultas todo esto se aplica para el nuevo tracker }}} neosergio {{{ otra pregunta de cal: que store de rdf esta usando tracker por debajo }}} '''frade''' {{{ tracker traduce el SparQL a SQL, y usa SQLite realmente para almacenar las cosas la "magia" con que hacemos tracker eficiente, esta en esa traduccion en lugar de usar una tabla con 3 columnas.... (la primera solucion qeu se nos viene a la cabeza si pensamos en como almacenar tripletas) traducimos cada clase a su propia tabla, con las propiedades basicas como columnas de la tabla y las propiedades entre clases, como una tabla separada, estilo Entidad-relacion }}} '''frade''' {{{ tracker 0.6 usaba la tabla con 3 columnas y el rendimiento es malo cuando la informacion crece un tabla por clase significa que 10000 contactos no afectan el rendimiento de las queries sobre 100 ficheros de musica (el rendimiento es proporcional al tamaño de la tabla, y cada clase esta en una distinta) }}} '''frade''' {{{ preguntas? }}} neosergio {{{ una mas pregunta de cal: se han planteado la integracion de ciertos contextos del repositorio semantico con aplicaciones de pim para dar permiso a grupos de contactos a realizar consultas sobre nuestro repositorio }}} '''frade''' {{{ el asunto de compartir la informacion de tracker ya salio a discusion alguna vez introducir usuarios y permisos es muy complejo ... se podria hacer, pero de momento la idea es mantener tracker como algo para el usuario a lo que solo el usuario tiene acceso }}} '''frade''' {{{ aplicaciones por encima de tracker serian las encargadas de la comparticion/restriccion de acceso de alguna manera, cualquier con acceso a la sesion dbus del usuario, tienen acceso a su tracker... (no esta descartado que en el futuro haya granularidad mas fina en permisos, pero sin planes concretos, es un asunto complejo) }}} '''frade''' {{{ otra pregunta? }}} neosergio {{{ no hay mas al momento }}} '''frade''' {{{ bien, pues creo que podemos acabar hablando de GNOME3 o mas bien de mi idea de GNOME3 y como tracker puede ayudar en ella }}} '''frade''' {{{ Si por fin nuestra idea de tracker vuela, conseguimos reunir una masa critica de aplicaciones que metan informacion entonces podemos ofrecer al usuario una experiencia de escritorio _nueva_ hay gente que pide "mostrar el status online de la gente a la que le escribo un correo" eso seria posible si tenemos esa informacion en tracker (email esta, contactos estará cuando telepathy empiece a usar tracker) mostrar documentos relacionados, el viejo projecto del "dashboard" sera casi trivial de implementar... y ademas hay otros dos proyectos que complementan (y en cierta medida se solapan) la oferta de tracker CouchDB sobre sincronizacion y Zeitgeist aportando informacion "extra" }}} '''frade''' {{{ con estos 3 componentes, GNOME puede tener una "capa de datos" potente le sumas GNOME Shell para la gestion de ventanas y podemos ofrecer un escritorio radicalmente nuevo }}} '''frade''' {{{ y para la gente que este en el canal buscando ideas para programar, hay un monton de huecos donde ayudar 1) plugins para programas (tomboy es presa facil!) 2) widgets para hacer mas facil el acceso a tracker 3) refactorizar programas para que admitan varios backends (y uno de ellos tracker, por supuesto) 4) hacer una UI que explote la informacion relacionada... }}} '''frade''' {{{ (otra presa facil para el punto 1) es hacer plugins para EOG) y sobre 2) es casi vergonzoso que no haya un widget para poner tags en gtk [al menos que yo conozca] }}} '''frade''' {{{ y ... mas o menos eso es lo que queria contar sobre tracker :) cualquier pregunta sobre el tema, no dudeis en escribirme ifrade@gnome.org o uniros al canal #tracker aqui en GIMPNet (en ingles, pero podeis encontrarme alli y abrir un privado) tenemos una lista de correo, como es habitual (tambien en ingles) }}} neosergio {{{ la charla ha estado completa, interesante, y pues ya saben hay mucho por colaborar me parece que dejamos la moderacion para las preguntas ya finales si alguien tiene alguna antes de cerrar entonces, gracias por tu tiempo frade y la voluntad y esfuerzo para la charla de este mes }}} '''frade''' {{{ muchas gracias a todos por vuestra atencion }}}