Recursos y Modelos

Uno de los problemas de diseño que tiene el TP actual es que no separamos claramente dos cosas:

• El acceso al recurso
• La forma de interpretar ese recurso

Eso nos llevó a varias soluciones basadas en métodos, dominios, inspectores y otras abstracciones que nunca acabaron de cuajar.

Pongo un ejemplo para que se vea claro. Imagina que tienes un fichero "trabajo.zip" en el directorio "cosas" en tú máquina y que estás sirviendo a la vez ese mismo directorio con un servidor web y uno ftp. Eso te da dos URI's posibles para acceder al fichero.

• http://example.org/cosas/trabajo.zip
• ftp://example.org/cosas/trabajo.zip

Para conseguir el fichero (el "recurso" en un sentido más general) puedes utilizar dos métodos distintos, pero no estás asumiendo aún nada sobre el contenido o estructura del fichero. Para eso necesitas un modelo (por medio de un inspector).

Ahora imagina que tienes un inspector capaz de visualizar un fichero .zip como si fuera un directorio, pudiendo ver el nombre de los ficheros y sus atributos. Esto no es nada nuevo, gvfs + file-roller hacen eso mismo hoy día en GNOME (o lo intentan).

La conclusión es que el mecanismo de acceso al recurso y la forma de entender el recurso DEBEN ser cosas diferentes y desacopladas. Eso no lo logramos en la versión actual de TP y es fuente de muchos problemas.

Así que yo distinguiría entre Recursos e Inspectores, de modo que los inspectores necesitan una referencia a un recurso y nunca acceden "físicamente" a ningún fichero ni dispositivo. Esto encaja perfectamente con el modelo de tres capas en el que el Recurso estaría en la capa de persistencia/acceso y el Inspector en la capa de modelo.

• Ejemplos de Recursos: ftp, http, bluettooth, ssh, ice, etc.
  
• Ejemplos de inspectores: zip, camera, json, media, hg, etc.

Desde el punto de vista de la plataforma eso es todo. Se asume que "alguien" crea un Recurso a partir de una URI y después le pasa la referencia a un Inspector. Algo como:

zip = InspectorZip(ResourceHTTP("http://example.org/cosas/trabajo.zip"))

Pero desde el punto de vista de TP debe haber una forma automágica de crear Recursos a partir de URI, algo que es en principio muy sencillo, basta mirar lo que hay antes del ://.

Pero además debe haber una forma de elegir el Inspector más adecuado y también tener la posibilidad de cambiarlo si el usuario quiere. Un .tgz se puede ver con un inspector de "gzip" pero también con uno de "unp".

En muchos casos eso se puede hacer mirando la extensión del fichero pero en otros no es tan fácil. Por ejemplo, un directorio que contiene un repo subversion... ¿cómo se sabe que lo es? "ssh://example.org/repos/mi_proyecto". Lo que hace subversion concretamente es crear una URI del tipo "svn+ssh://example.org/repos/mi_proyecto". Bueno, es una opción, pero estaría bien algo un poco más inteligente si es posible.

Otro caso es un objeto tipo "ice://objeto1 @ adaptador". Aquí el Recurso es Icd pero ¿qué Inspector usas? La forma de determinarlo es invocar el método ice_ids() del objeto y buscar inspectores que lo puedan manejar. Algo que es MUY distinto a mirar la extensión o el prefijo de la URI porque implica USAR el recurso.

Obviamente puede haber Inspectores que solo tengan sentido con un Recurso concreto pero eso no significa que deban estar acoplados, precisamente porque puede haber muchos Inspectores que pueden usar un mismo tipo de Recurso y algunos de ellos pueden no tener esa limitación.

Y para terminar, imagina que el zip del que hablaba antes contuviera a su vez un .tgz o una base de datos sqlite... También queremos verla...

Bueno, cómo véis, más problemas que soluciones... pero bueno, estamos capturando requisitos.