Organización de ideas

El pasado viernes estuvimos discutiendo algunos aspectos interesantes de TwinPanel. De ahí, obtuvimos varias ideas clave y otros puntos un poco difusos (al menos, para mi).

Partimos de la idea de Recurso, que fué una de las más controvertidas ;). Un Recurso no deja de ser un modelo (de acceso, si se quiere aclarar), al igual que los otros modelos que ya teníamos (los modelos de datos). La distinción que queríamos hacer principalmente se mantiene (la que diferencia entre el mecanismo de acceso a los datos, y la manipulación de estos), pero no se añade (a primera vista) una capa más (aunque esto es discutible :P)

Queremos respetar el MVC a toda costa, algo que me parece muy bunea idea, dada la pluralidad de interfaces de usuario que vamos a tener.

También quedó claro que la arquitectura para todo esto nos la provee perfectamente Ice, más concretamente IceBox + Slice. Usaremos el evictor de IceBox para gestionar dinámicamente los plugins instanciados (una pena que PyIceBox no tenga evictor, así que o lo implementamos o usamos otros lenguajes...). Por tanto, algo en lo que tenemos que trabajar primero es en la factoría de plugins.

Si, por ejemplo, queremos inspeccionar una URI dada, como "http://www.google.es", tendríamos primero que comprobar si denota un proxy válido (pues cualquier cosa que se desee explorar, deberá primero tener forma de proxy). Si no lo es, habrá un componente que se encargue de convertir esa URI. Ese componente, que posiblemente esté asociado a la factoría, deberá buscar un plugin capaz de manipular ese recurso, en este caso, un plugin para HTTP. Se creará (o se retornará) una instancia que manipule nuestra URI y ya tendremos el proxy que buscábamos (al modelo de acceso). Ahora, necesitaremos otro plugin para manipular el contenido del recurso, que se creará de forma análoga. Por último, una tercera entidad deberá representar de forma visual el contenido de los datos, aunque esta parte no es imprescindible, pues este modelo puede ser fuente para otro modelo, que a su vez... Sí, los modelos son 'stackables' :)

Como vemos, otra labor vital que resolverá parte de los problemas actuales de TP, será definir las interfaces para todos los tipos de modelos necesarios.

Un problema que tendremos que resolver será el mecanismo para decidir que modelo escoger. Por ejemplo, el de HTTP puede ofrecer una interfaz de tipo FILE, la más común. Pero también se puede diseñar un interfaz de tipo HTTP, que implemente los verbos correspondientes: get, post, etc. En el siguiente nivel (modelo de datos), ocurre exáctamente lo mismo, y también en la capa de presentación.

Por otra parte, en lo que se refiere a la factoría, también se han oido ideas curiosas que hay que resolver, como el hecho de que sea distribuida (y por tanto, sea necesario un mecanismo de descubrimiento de "factorías", o búsqueda, con algo como ASD.Search).

El caso es que esto está tomando un cáriz interesante :D Ahora te toca a ti, busca los siete gazapos :P

再见!

URI, URL, URN y otras hierbas

Todo Resource debe ser identificado de alguna forma. A ser posible, que sea 'human readable' (como el XML :P). Esto no es nada nuevo, pero sería interesante comentar las opciones que tenemos, sean o no estándar, y que se adapten a nuestras necesidades. Sobre todo, sería muy interesante poder coger cualquier 'identificador' estándar y poder explorarlo.

En la primera versión de TwinPanel, usábamos algo llamado 'URI', pero que no se adecuaba a ningún estándar. Por ejemplo, para explorar un objeto Ice, usábamos algo como "ice://objeto -t:tcp -h host -p 1234". En los objetos complejos, que tienen jerarquía, separábamos el objeto de la "ruta" hacia el nodo, por ejemplo "ice://[objeto -t:tcp -h host -p 1234]/cameras/garage/". Si además es necesario añadir autenticación, entonces se puede añadir antes del recurso, por ejemplo "ftp://user:passwd@hostname/path/to/file".

La primera parte de estas URIs (lo que hay antes del '://') especificaba el tipo de acceso al recurso (ice://, http://, etc.). Ahora bien, nos surge la necesidad de especificar el acceso al recurso, pero también el tipo del recurso. Por ejemplo, subversion utiliza uris de la forma 'svn+ssh://box/path'. El recurso es un repositorio subversion, y la forma de acceder a el es por medio de ssh. A nosotros nos pasa algo parecido. Por ejemplo, tenemos un fichero zip, accesible por medio de http. En este caso, se podría omitir el modelo y dejar que algún mecanismo de introspección detectara que es. Esto es muchas veces caro, y alguna inviable. Por eso, surge la necesidad de ampliar nuestro esquema de nombrado de recursos.

Un ejemplo algo más claro: una imagen SVG modelada como un byteseq de Ice. Si no se especifica de algún modo el contenido de ese byteseq, se puede interpretar de muchas formas. Se podría detectar, analizando el byteseq, pero para eso, habría que obtenerlo primero (además, no siempre es posible detectar así el modelo). También se podría especificar como una propiedad, pero entonces se complica si queremos modelarlo como otra cosa (por ejemplo, como texto plano). Si esta información la añadimos al identificador del recurso, es inmediata la elección del modelo, y nos permite cambiar fácilmente entre distintos modelos.

Ahora, sería interesante elegir un esquema de direccionamiento. Uno de ellos podría ser URN, un identificador independiente de la localización, que es un tipo de URI. Básicamente, este esquema se compone de un identificador del dominio, mas un identificador dependiente del dominio. Algo así como 'urn:ice:object@adapter'. Esto sería perfecto si no fuera por la cantidad de restricciones que tenemos para componer el identificador dependiente del dominio. Cosas vitales como '/' o '[]' no son admitidas. Sí lo son en formato hexadecimal, lo cual es una carga a la hora de trabajar manualmente con ellas. Una posible solución pasaría por permitir al usuario entrar URN 'prohibidas' y convertirlas inmediatamente para manipularlas internamente. Así, se adaptaría al estándar a la vez que serían manejables. En esos casos, obviamente, prescindiríamos del prefijo 'urn:', con lo que tendríamos cosas como 'http:svg:server/path/file.svg', que sería traducida internamente a 'urn:http:svg:server%40path%40file.svg', o algo parecido.

¿Qué opinais?

Cuestión de conceptos

Bueno, dado el anterior post de David, ahora tengo claros algunos conceptos más. Pero, para mi sigue siendo un montón de ideas en el aire, con relaciones parciales entre ellas. Necesito ponerlas en algún sitio, establecer esas relaciones y verlo todo como un conjunto conexo. Por eso, me gustaría empezar a distinguir y definir conceptos. Por supuesto, las cosas que falten, ya sabéis... comentarios.

A primera vista, los conceptos son: Recurso, Modelo, URI, Factoría, Inspector, Skin... TwinPanel :P De momento, un conjunto de nombres. Pongámosle caras.

• Recurso: es el "qué". Aquello que se quiere utilizar, es la entidad a la que se desea acceder (no se me ocurren palabras más genéricas que realmente digan algo).  Por ejemplo, un fichero zip en un directorio ftp de cierta máquina de nuestra red (como URL, sería "ftp://abox/ftp/afile.zip"). A nivel de TP, el recurso se puede considerar como un "proxy", un representante de lo que se quiere utilizar, y que sabe como acceder a él. El recurso (para TP) encapsula el mecanismo de acceso a esa entidad.
  
• Modelo: especifica cómo se debe manipular el recurso. En el ejemplo anterior, tendríamos un fichero comprimido. El "modelo" es quien sabe lo que se puede hacer con ese fichero comprimido: leer su contenido, descomprimirlo, añadir otros ficheros, etc. El modelo es una entidad abstracta, que será instanciada por los Inspectores.
  
• URI: es un identificador del recurso. Bien puede decir qué es (URN), o bien dónde está (URL). Este concepto es el más claro, aunque su estructura no la tenga tan clara... :D
• Factoría: es la entidad encargada de proveer los componentes necesarios para inspeccionar determinado recurso. Antes, era un componente bien conocido, pero puede que cambie un poco su "personalidad".
  
• Inspector: es el encargado de tratar con el contenido del recurso. Es la instanciación de un modelo. Para cada modelo puede haber varios inspectores, dependiendo de factores como la tecnología usada para tratar el recurso. Así, para el zip, tendríamos un inspector que usase "zip", y podríamos tener otro que se sirviera de un mecanismo online para ver el fichero, por ejemplo.
  
• Skin: es la representación del recurso de cara al usuario: la vista del mismo. Este concepto tampoco ha variado mucho desde sus inicios, aunque sí la tecnología subyacente (¡ahora puede estar distribuido!). Utiliza un inspector para acceder al recurso.
  

Voy a intentar desempolvar los conceptos de UML para dibujar un ejemplo de clases.

Aquí se representan sólo las relaciones entre recursos, modelos e inspectores, y con ejemplos para verlo un poco más claro.

Ahora, podemos discutir cosas. Por ejemplo, la interfaz que debe conocer un modelo de cierto recurso. Si es diferente para cada recurso, un modelo dado debe ser consciente de los recursos para los que está disponible, algo que no es desable. Entonces, debe ser la misma para todos los recursos. Habría que ver si es posible una interfaz que sea práctica para todos los casos posibles.

De todos modos, ¿qué pensáis?