En el artículo del otro día mencionábamos el papel que Safari juega en la estrategia de Apple para conseguir crear un ecosistema de aplicaciones web independientes de Adobe y Microsoft, y especialmente amistosas con el Mac.

Decíamos que Apple estaba usando una "pinza", con SproutCore por un lado y Safari por el otro. Y como decíamos aquí, se esperan cambios serios en Safari, y no sólo en cuestión de rendimiento. Entre ellos, nos interesan dos: la posibilidad de "guardar como aplicación" una página, y la posibilidad de que una aplicación web guarde datos en el Mac.

Sobre lo primero ya hemos hablado bastante (sigo recomendando ver y catar Fluid). Es una prestación que permite guardar en el Mac una especie de acceso a esa misma página, vista como si fuera una aplicación y no una web, y tratarlo como una aplicación en todos los sentidos. Al parecer está disponible en la versión de Safari 4 que ya están catando algunos desarrolladores bajo NDA.

Lo segundo tiene muchas más consecuencias. Se trata de la posibilidad de que una aplicación web (una página que funciona como un programa) guarde datos en local. Pero no datos sencillitos como una cookie, sino datos complejos. Bases de datos, en formato SQL, siguiendo la especificación que propone el estándar HTML5 (si quieres saber mucho más sobre el tema, puedes ver los detalles aquí). Todo respaldado y accesible por la API correspondiente.

¿Para qué sirve ésto? En resumen, para que cada aplicación web (autorizada para ello) se abra su base de datos en nuestro Mac y guarde ahí los datos que necesite para sus cálculos, minimizando la necesidad de conectarse con el servidor y aumentando la capacidad de generar operaciones intermedias. Desaparece así la principal diferencia entre un programa de escritorio normal y una aplicación web.

Las bases de datos se crean y modifican con unas condiciones de seguridad bastante fuertes (sólo las puede tocar la aplicación que las creó) y aparentemente bien aisladas, por lo que no deberían representar un riesgo de seguridad. Se generan con un componente llamado "servidor SQLite" incorporado en WebKit, y se guardan en ~/Library/WebKit/Databases/.

Y además, el inspector de web integrado en WebKit (y llamado imaginativamente WebInspector) que servía para medir las respuestas del servidor y seguir los errores en la ejecución de los scripts (entre otras cosas), ahora puede usarse para gestionar las bases de datos que se crean.

Esta prestación ya está disponible en las últimas versiones "nightly build" de WebKit para Mac (aunque no para Windows: parece que ahora mismo hay un desfase serio entre Safari para Windows y WebKit para esa plataforma, y hasta que se normalice no van a sacar más "nightlies"para ella). Y de hecho, ofrecen una demo de la prestación en el site del proyecto para los que se hayan descargado WebKit y quieran probarla.

Trabajo offline

Aunque de momento no se ha implementado, la capacidad de guardar datos en local significa que (dentro de un orden y segun el caso) la aplicación podría seguir funcionando offline. Una vez que tiene los datos que necesita (p.ej. los datos de producto de un catálogo) puede realizar los cálculos y operaciones que sea necesario (p.ej. la toma de doce pedidos nuevos) y sincronizarlos con el servidor días después al volver a donde pueda conectarse. Pero puesto que a priori no hay límites al tipo de datos que se pueden descargar, tampoco hay límites al tipo de operaciones... si no tiene que sincronizarse en tipo real con el servidor, se puede hacer offline. Pero como decimos, aún no se ha implementado el modo offline. Y quizá Apple no lo vea interesante.

Gears y HTML5

En este caso, el trabajo de Apple sigue la especificación HTML5, pero no es pionero: otras iniciativas han pasado ya por ahí. En concreto, la más conocida (y ya mencionada) es Google Gears, que tiene un objetivo análogo y bastante más madurez (y usuarios). De momento, sin embargo, Gears no se ata al incipiente estándar HTML5 tanto como WebKit, aunque están tan cerca que hacerlos compatibles parece ser tarea rápida.

Ya hay gente trasteando con la idea de acercar la especificación (que cambia) y las implementaciones (que también), para crear un sólo estándar, o algo que se le parezca, en vez de varias metodologías incompatibles. Cabe pensar que una de las piezas de SproutCore tendrá mucho que decir sobre ésto, y que Gears eventualmente seguirá HTML5.

¿Yellow Box, otra vez?

La suma de todo ello está otra vez haciendo asomar comentarios acerca de la vieja idea de "Yellow Box" de Apple. Efectivamente, la suma de estas prestaciones y las herramientas de desarrollo de Apple (más un servidor en alguna parte) podrían permitir que cualquiera, en cualquier ordenador o smartphone con una versión de WebKit o sus derivados, ejecutara una aplicación creada con SproutCore en su escritorio. Pero queda bastante lejos de la idea original. SproutCore, de momento, no tiene la potencia de los frameworks de Cocoa.

Aunque la idea tiene su gracia ;-).

Puedes comentar el artículo en los foros.

Tags: html5 gears safari 4 webkit sql sqlite apple
View blog reactions