Ir al contenido principal

No solo de interfaz vive el hombre

Hace tiempo que sigo con interés el tema de “web versus gui” o “webtop versus desktop” o como quieran llamarlo. Es el tema de su las futuras aplicaciones serán aplicaciones Web todo “hosteado” por ahí y accesible desde cualquier lado (Internet) o en realidad las aplicaciones “locales” tienen largo tiempo de vida por delante.

Mucha agua ha corrido debajo de ese puente e intuyo que mucha más ha de correr aun para considerarla una discusión zanjada, de todos modos hay “hitos” que me parecen importante destacar el AIR (Adobe) parece uno de ellos.



Creo que "postear" algo del tema y no hablar de un jugador reconocido como es google es un despropósito, entre muchas cosas más creo que Google ha demostrado que se pueden (tecnicamente) hacer aplicaciones Web con una interfaz realmente “dinámica y atractiva” casi como una aplicación GUI. 

Ahora el tema no se agota ahí, si bien la interfaz y su "dinamismo" es importante, es todo un tema larguísimo de analizar, incluso muchas veces me da la sensación de que apuntamos a la solución (a veces incluso a productos, digamos que cada uno llevado agua para su molino) y no al problema en sí o los pilares que sustentan una decisión/solución u otra.

En fin, en cualquier caso lo que quería comentar en este post es una noticia que me pareció relevante (un hito) en esta discusión: Adobe está lanzando AIR (Adobe Integrated Runtime).

Independientemente de si es Apollo renombrado-recargado, independientemente de qué pasa con Google Gears, qué pasa con Microsoft Silverlight, diferencias, coincidencias, hay dos puntos que me parecen especialmente interesantes en esta movida:

Base de datos local.
Tanto con AIR como el Google Gears se puede tener una base de datos local (SQLite) para poder mantener información localmente (valga la redundancia).

Es una base “liviana”, en C, embebible en una aplicación, sin requerimientos de setup complicados, no leí nada de licenciamiento pero supongo que es re-distribuible (por lo  menos). También parece LOCAL LOCAL o sea, no parece pensada para "multi-usuario", pero no profundicé en el tema, solo por arriba.

Out of the browser
Las aplicaciones AIR pueden ejecutarse dentro del respectivo “plug-ins” o directamente sobre el AIR sin necesidad de un browser. Con esto lograrían acceder al “file system” local, entre otras cosas.

Confieso que ambas cosas me suenan a aproximarnos más al “desktop” es decir, la dependencia de una máquina específica donde tenga TAL base de datos con TALES datos, donde tenga TAL file system con TALES archivos, que a la idea de “webtop” que es “no tengo nada, todo está centralizado en un hoster”.

Si tomamos ese camino creo que nos enfrentaremos nuevamente a los mismos conocidos problemas por los cuales el webtop nos atrae: deployment, sincronización con los clientes, limitación de la movibilidad, etc.

No se, se confunden en mi mente AIR, con el MS Framework, con una JVM y se confunde SQLite con sus predecesores como Cloudscape.

Al menos por ahora, solo habiendo leído por arriba la información y sin mucho tiempo para entrarle más a fondo.

En cualquier caso, si esta esa la movida: ¿Está bien? ¿Está mal?
No lo se, ni soy quien para decirlo, pero parecería que la movida “100% webtop” tiene sus bemoles y parecería que tienden a resolverse del “viejo” modo.

Al final del día creo que todo se trata de converger y las radicalizaciones no aportan mucho y como todo hijo tendrá la carga genética de ambos padres, de eso se trata la evolución.

Comentarios

  1. Revise el tema de la licencia del SQLLite y es PUBLIC DOMAIN, que significa esto?
    Les transcribo parte del texto que pueden encontrar en el sitio de esta base de datos:

    Anyone is free to copy, modify, publish, use, compile, sell, or distribute the original SQLite code, either in source code form or as a compiled binary, for any purpose, commercial or non-commercial, and by any means.

    Referencias
    http://www.sqlite.org/copyright.html
    http://en.wikipedia.org/wiki/Public_Domain

    ResponderBorrar
  2. Continue leyendo sobre la base de datos y permite concurrencia de aplicaciones.

    "Can multiple applications or multiple instances of the same application access a single database file at the same time?
    http://www.hwaci.com/sw/sqlite/faq.html#q7"

    Es una base de datos interesante para desarrollo de aplicaciones monousario o con pocos usuarios, o aplicaciones donde la base de datos recide en un CD, etc.

    Por más información sobre cuando usar SQLLite la pueden encontrar en: http://www.hwaci.com/sw/sqlite/whentouse.html

    ResponderBorrar
  3. Si, había visto eso de "multiusuario" pero es "multiusuario readonly":

    "Multiple processes can have the same database open at the same time. Multiple processes can be doing a SELECT at the same time. But only one process can be making changes to the database at any moment in time, however."

    Lo sospeché cuando a "vuelo de pájaro" vi: "Nested transactions - The current implementation only allows a single active transaction." (http://www.sqlite.org/omitted.html)

    Igual, convengamos que para lo que la quiero (en principio intuyo que metadata o bajar información local que luego puedo manejar "desconectado", etc) todo parece muy "monousuario" por lo cual en ese alcance no parece un problema esa limitación.

    Igual mi post apuntaba más a la "arquitectura" que a si se usa SQLite o Cloudscape o MDB o lo que sea, en la medida que se use algo "local" se pierde (bastante) de la gracia del "webtop".

    ResponderBorrar
  4. Ya había leido un poco sobre Google Gears (http://gears.google.com/) , incluso en el lanzamiento de Adobe que menciono en el post original hay una referencia al mismo.

    De todos modos siguiendo el tema en internet encontré un artículo de un "muy exitado" David Berlind (http://blogs.zdnet.com/Berlind/?p=509) que parece haber ganado la lotería con el Google Gears.

    En cualquier caso no me siento del todo solo y juro que yo no puse este post en dicho artículo:
    http://talkback.zdnet.com/5208-10741-0.html?forumID=1&threadID=34808&messageID=640421&start=-1

    Debo aclarar que no estoy en contra de Google Gears y mucho menos de la innovación, de la cual Google debe sentirse orgulloso en los últimos años, simplemente que me suena un camino trillado el de tener una base local "liviana" para resolver el problema del "offline". Por ahora no me suena una solución muy "innovadora" respecto al problema de "estar desconectado", talvez por el lado del API común, no se...

    ResponderBorrar
  5. Siempre es dificil la futurologia, pero es cierto que NO todo es WEB en esta vida. Existen y existiran siempre, aplicaciones de tipo Desktop que esten pensada para correrse en un ambiente local, eventualmente una red local, que siempre seran necesarias.
    Esto para aplicaciones de distintos tipo: ej. mantener una metadata, programas tipo entrypoint de datos, o simplemente una PYME que precisa su programa de facturacion local.
    Y esto no solo ser usado en empresas menores, sino que es la forma de dar solucion a operativas muy especificas, por ej. es claro que los organismos publicos de nuestro pais, entregan aplicaciones para ser instaladas localmente y asi cargar la informacion, con los controles y formatos adecuados, muchas de ellas hechas en Genexus.
    Como debe ser esta aplicacion local ?? SIMPLE !!!, debe contar con su setup, y que sea todo autocontenido: aplicacion, base de datos, registro, etc. y salir andando.

    Que pasa con una aplicacion web ? del punto de vista del usuario, para usar y actualizar la aplicacion es solo abrir el browser, genial !!
    Pero si tiene que instalarla... intervienen un conjunto de piezas de sofwtare que hay que coordinar para lograr hacerlo andar: servidor web, base datos, seguridades varias (firewall, https), runtime de java / .net etc. etc. Que podrian ser realizadas con un setup, hasta cierto punto !!, más algun procedimiento... en fin, nada que pueda hacer un usuario final.

    Moriran las aplicaciones GUI, creo que NO, pero si hay que buscar un sustituto digno para las aplicaciones VB / VFP que forman gran parte de la comunidad GX.

    ResponderBorrar

Publicar un comentario

Entradas más populares de este blog

Abrir links con aplicaciones nativas y no el browser (deeplinking)

El problema que tengo con algunas aplicaciones Android/iOS es que cuando recibo un link por algún medio (mail, tweet, etc) al abrirlo me lo abre con el browser, en lugar de abrirlo con una aplicación nativa asociada a ese “contenido”. Por ejemplo, si recibo un link a un tweet espero que lo abra con alguna aplicación de twitter que tenga instalada y no con el browser. De modo análogo si recibo un mail con una nota de prensa de un medio X y tengo la aplicación de ese medio X instalada, espero que el link lo abra con la aplicación nativa y no con el browser. Lo mismo quisiera con mi aplicación de "banking" o cualquiera que tenga instalada y sepa manejar ese "contenido" (link). Los motivos son bastante obvios pero los resumo en: la experiencia de usuario es mucho mejor en la aplicación nativa que en el navegador. Parte importante del tema es que el mismo link sea válido tanto para ver el contenido en el browser como para verlo en la aplicación, porque como prove

¡A la salud de mi KB!

Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud". En este sentido KBDoctor  es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB. También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices. A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server". En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".

Rocha:Constantes tipo fecha

En la Rocha se soportan constantes del tipo fecha o fecha-hora con formato ANSI/ISO (AAAA-MM-DD HH:MM:SS).  Tecnicamente (Sintáxis): <date>::=    [0-9]{1,4}"/"[0-9]{1,2}"/"[0-9]{1,2} | [0-9]{1,4}"."[0-9]{1,2}"."[0-9]{1,2} | [0-9]{1,4}"-"[0-9]{1,2}"-"[0-9]{1,2} <hms>::=    [0-9]{1,2}[ap] | [0-9]{1,2}":"[0-9]{1,2}[ap]? | [0-9]{1,2}":"[0-9]{1,2}":"[0-9]{1,2}[ap]? <constant> ::=   "#"<date>"#" | "#"<date> <hms>"#" | "#"<hms>"#" Funcionalmente Se pueden utilizar esas constantes en las reglas, eventos, propiedades, etc (todo lugar donde se utilice el parser): Algunos ejemplos básicos: &FechaInicial=#2007-01-01# &FechaHoraInicial=#07-1-1 11:15a# &HoraInicial=#11a# Me parece bueno no tener que escribir funciones (CTOD, TTOC) sobre constantes tipo char para lograr una fecha y mucho mejor aun en