Hace algunos días me pidieron que estudiara alguna manera de validar que una fotografía cumplía con ciertos requisitos de densidad y medida en pixeles: un requerimiento simple, que exige acceder a metadatos de la imagen. Desde el punto de vista de nuestros modelos de Plex, esto significa usar un API, ya que no existen dentro del conjunto de funciones propias del producto, ni tampoco en ninguno de sus patrones de tecnología, alguna función preelaborada que permita obtener esa información.
Un API es un trozo de código específico de una plataforma que funciona encapsulado: en su interior resuelve una necesidad específica, en este caso, tratar metadatos de una imagen, intercambiando información con el modelo a través de parámetros. Así, el modelo se mantiene a nivel abstracto, y se relaciona con código específico de plataforma a través de un marco de inicialización que resuelve la relación entre el nivel del modelo y el del código encapsulado. El marco de las APIs que Plex maneja es relativo a plataformas específicas: c++ para clientes Windows de código no administrado (en términos del marco .NET) u ODBC, un motor de VBscript incrustado para VBscript, c# para .NET, y java o RPG para las variantes respectivas. Ya hace tiempo existe en la comunidad de Plex el estilo de definir un API de tal forma que responda a múltiples plataformas, por medio de metaoperaciones, que permitan intercambiar los parámetros entre el modelo y el código encapsulado, que será uno distinto por variante, y se resolverá en tiempo de compìlación según metaoperaciones que interroguen al modelo acerca de qué lenguaje se ha configurado. De esta forma, un sólo objeto API permite representar en un modelo su solución para tantas variantes como sea necesario y posible.
¿Estas son las únicas variantes posibles? Aunque hasta donde conozco, nadie lo ha intentado, existe una posibilidad de "sobrecargar" Plex para agregar APIs de otra plataforma o lenguaje: Plex sigue el modelo .COM, y permite importar un componente, y utilizar sus métodos y variables públicas como parte del modelo. Es entonces posible añadir transformaciones que habiliten otra variante, al menos al nivel puntual de una API. Utilizando elementos similares por otra vía, Websydian primero, y Webclient después, permitieron agregar capas de arquitectura web completas a un modelo de Plex.
Pero ahora, volviendo al pedido de lectura de metadatos de imágenes...Primero, restringimos el alcance del API a una aplicada a un modelo WinC, es decir, uno de plataforma Windows de modelo Win32, al menos para su primera versión: el horizonte de aplicación abarca por lo menos los próximos tres años. No está claro si en el futuro la aplicación continuará sobre Windows o Java, y en el primer caso, si sobre Win32 o WinRT. Digamos de todas formas que WinRT todavía no está soportado sobre Plex, lo que estrechaba el marco de posibilidades. Ahora bien, ¿qué alternativas hay disponibles para trabajar con imagenes escritas en c++ o c? En una primera revisión, encontré varias alternativas; Adobe XMP Toolkit, ExifTool (en modo de línea de comandos), Exiv2, y especialmente el
Windows Imaging Component, o el objeto
PropertyItem (en
System.Drawing.Imaging Namespace)
, ambos de Microsoft. Con algo de entusiasmo, comencé pesando las posibilidades de estas dos alternativas de Microsoft. Trabajando con Visual Studio y sobre una plataforma Windows ¿qué alternativa más "natural" puede considerarse que la del propietario de la plataforma? Sin embargo, luego de revisar la documentación (algo escasa en general), encuentré su uso demasiado exigente para el caso que debíamos atender: En primer lugar, la clase PropertyItem parecía más simple y directa de usar (a pesar de que tampoco estamos hablando de pocas líneas de código), pero aparecieron un par de observaciones (
1,
2) que es necesario tener en cuenta, sin hablar de las posibles dependencias de versión del framework .NET. En el caso de
WIC, examinando la documentación claramente marchabamos a matar moscas a cañonazos. Tanto por la complejidad relativa al objetivo a resolver, como también por la ambigua situación de evolución y deriva de .NET, Win32 y WinRT,decidí volver a evaluar otras opciones de código abierto, y finalmente adopté
Exiv2, pero aún de una manera más simple: no recurriendo a la librería c++, sino usando el comando de consola exiv2, que permite acceder a la mayoría de los estándares de metadata...sin necesidad de asegurarse de que estén instalados los codecs adecuados...
En fin, resuelta la estrategia, en un par de días cerramos el problema con un código simple, reducido, y fácilmente ampliable a la obtención de otros atributos. En una situación de transición de la plataforma de Windows como la actual, es preferible quedar libre de dependencias y compromisos, si es posible. En tanto, ActiveX, VBA, VB for Office, c++ y en alguna medida .NET y .COM, atraviesan la borrosa frontera entre Win32, WinRT y otras alternativas que puedan sumarse a "un solo Windows"...
