Vivimos presos del lenguaje, la televisión, la estupidez y la moda [1], pero sobre todo subsistimos encorsetados en la inercia de la costumbre, “hija de la pereza y madre de la constancia” que decía Larra. El actual usuario informático pavloviano pide bien poco: pequeños cambios, si acaso alguno, fáciles de asumir. Así cuando se difundieron el WWW, los paginadores y el fácil lenguaje de marcas HTML, el inerte usuario apreció un nuevo medio de prolongar y extender a miles de lectores su egoísta y miserable condición personal, de forma que los habituales autores de mensajes cortos en las secciones de intercambio de los diarios pasaron a publicar su fútil enjundia en el web. Realmente la aparición del paginador Mosaic originó, a tenor del pasmo presente, un cambio en la actitud de las personas “normales [2] ” respecto de Internet, de manera que, merced a la simplicidad efectista de las páginas HTML, aquéllos pasaron de simples observadores a cejijuntos internistas, cada vez más preocupados en el formato y longitud de sus páginas web [3]y en la recolección de visores autónomos de tipos de datos para sus paginadores. Empujado por esta demanda los paginadores rápidamente asumieron, a más de la interpretación de documentos HTML, servicios de FTP, Gopher, etc. El cambio fue realmente pequeño: cualquiera podía, y puede, redactar un texto en algo parecido al castellano, bordear algunos párrafos y palabras con fáciles marcas HTML, añadir algunos dibujos auto-promocionales y publicar el resultado final en cualquier servidor web. De esta forma el web rápidamente gana la atención de los usuarios, hijos de la televisión y el vídeo, pues el carácter anárquico y básicamente gratuito de Internet encaja a la perfección en el ánimo y condiciones del cliente medio: uno puede rebuscar continuamente en la basura esperando encontrar una gema o, cuando menos, una idea, frase o gráfico que hurtar. Naturalmente además de la gran zona mercantil y personal (si es que puede existir lo personal sin distinción individual) todavía existe en Internet un núcleo de comunicación científica. Pero entiéndaseme bien: yo no postulo la restricción, el control o las zonas de exclusión; únicamente cuestiono que el medio se convierta en fin. Cuando se adquiere un nuevo PC, usualmente con Windows 95 preinstalado, el nuevo usuario obtiene un paginador para el acceso a Internet que, como un sintonizador televisivo, recibe programas preconfigurados y facilita el abuso del zapping. Incluso percibe formas móviles (gifs animados, applets, etc.) que intentan remedar la esencial inmovilidad del contenido conceptual. Así que el nuevo usuario de Internet se acostumbra rápidamente a cambiar de URL como de canal televisivo, y rápidamente también infiere que así es como deben ser las cosas, de forma que pide únicamente algún pequeño cambio que pueda insertarse en tal esquema, con muy poco coste añadido, y que, además, le procure cierto grado superficial de innovación. “Si el paginador, con sus múltiples añadidos y mini-gestores, es la solución -pues funciona a escala masiva: he ahí la prueba-, sólo resta mejorar algunos flecos”. Y es que la costumbre, en canallesca definición de Véron, no es sino “una sirvienta que termina por casarse con el dueño”. CASTAÑUELAS
MARÍMBA [4] La historia, en síntesis, es como sigue: Jonathan Payne, el autor del depurador java, co-arquitecto de la primera versión de Hot Java y de sus protocolos de red, abandonó Sun para trabajar en Starwave en Febrero-95. En noviembre del mismo año Arthur van Hoff (ingeniero senior en JavaSoft, uno de los autores de “Hooked on Java” y uno de los padres del compilador Java, de los paquetes java.lang, java.util y java.io, el API de los applets y algunos de los primeros applets ejemplificadores) requirió a Payne su vuelta a Sun para trabajar en la segunda versión de Hot Java. Lo que ocurrió sin embargo, según palabras de Payne, fue que en el mismo noviembre éste propuso a van Hoff formar una nueva empresa que se dedicaría … a lo que fuera: ya se pensaría más tarde. Van Hoff reclutó por su cuenta, tras rechazar Mike Sheridan (coordinador del proyecto Java original: Green) el puesto de CEO, a Sami Shaio (padre putativo de la primera versión de la AWT) y a Kim Polese (única persona y motor del departamento de marketing de JavaSoft durante el período de expansión del pasmo Java). Así que en diciembre de 1.996 se fundó Marimba (Kim fue elegida CEO y Arthur CTO), en mayo-96 se publicitó y en agosto-96 la flamante compañía se permitió el lujo de elegir, entre sus varios postores, a la firma de capital riesgo que más les satisfizo: Kleiner, Perkins, Caufield & Byers. Forbes afirma que de los $100.000.000 del fondo Java de esta firma, al menos $4.000.000 se aplicaron a Marimba. Pero, ¿cómo se generó tanta expectación en tan poco tiempo? ¿Qué producto sostiene tanto anhelo y agolpamiento? Bueno, la auténtica verdad es que, como la empresa se montó sin producto concreto en mente (confiados en que era momento de montar empresas de tecnología), el soporte técnico de sus fundadores les llevó a la creación de un constructor de aplicaciones Java, que llamaron Bongo. Aquí es donde comienza el afán de ruido. Bongo es una bonita herramienta con muchos colores, añadidos y posibilidades. De hecho Marimba crea su propia biblioteca de widgets para solucionar algunas manifiestas imposibilidades de la AWT. Pero, claro, POINTCAST LOS PECADOS DE LOS APPLETS Tras examinar y adoptar la idea de selectividad personal de información, ¿cómo no establecer una larga lista de defectos para los applets, representantes del sistema tradicional de distribución de código que ahora resuena particularmente antiguo e ineficiente? ¡Claro que sí! Los applets, según van Hoff, no pueden sustituir a las clásicas aplicaciones autosuficientes porque disponen de un interfaz de usuario restringido en demasía, son incapaces de almacenar su estado interno, ocasionan largas, repetidas (cada vez que accedemos a una página web dada vuelven a cargarse los applets contenidos en la misma) y dolorosas descargas en Internet, incrementan el tráfico de los servidores y presentan problemas de escalabilidad. Se da, además, la dificultad añadida de su integración con un lenguaje de descripción de páginas cual es HTML, que ciertamente no es un lenguaje de programación, como sí lo es Java. “Oh, los applets tienen un gran futuro tras de sí”, podría afirmarse remedando a Lichtenberg. Y es que resulta que incluso en el modelo de componentes Java Beans los applets son sólo nombrados como un primer y demasiado elemental estadio de composición, de ruda integración con el resto: de nuevo Bruto asesta un golpe más a César. ¡Vaya! Realmente un applet, que se decía no era nada, resulta al fin ser bien poca cosa, pues su escasa funcionalidad (extensión de Panel) nació como una simple demostración tecnológica y su mismo éxito impedirá su renovación más allá de la extensión de la etiqueta HTML que aparece en el JDK 1.1. Claro que … a applet muerto, canal puesto. Y música, bongo y castañuelas. CASTANET, CAST-A-NET Y CANALES Castanet, la nueva línea de producto de la compañía Marimba que se presentó al mundo (junto con Bongo) el 07-10-96, se apoya en el ejemplo de los canales de noticias, que aquí son sublimados en canales (channels) genéricos por los que discurren código y datos por igual. Un canal es, pues, tanto un applet como una aplicación o un sitio web, pero su sustanciación viene de la mano de las herramientas con que Marimba le da soporte: clientes emisores (tuners), servidores transmisores (transmitters), repetidores (repeaters) y proxys. |
|||
|
|||
Según van Hoff, los requerimientos de un sistema de distribución a través de Internet, que naturalmente la arquitectura de Castanet satisface, son: escalabilidad, robustez, transparencia en su uso, posibilidad de monitorización, fácil personalización, replicación de sitios web, incrementalidad y, significativamente, la posibilidad de usar el contenido distribuido sin estar conectado a Internet. A lo expuesto habría que añadir una adecuada capacidad de servicio por canal, que van Hoff cifra en un millón de usuarios, cuatro actualizaciones (versiones) de canales por hora y cuatro peticiones de carga por suscriptor, con un límite de cuatro millones de peticiones por hora. Bueno, los números suenan bien. Lo malo es que los números siempre suenan bien. SINTONIZADOR Ésta es la pieza clave del esfuerzo mercadotécnico de Marimba, pues representa al software cliente que, en la actualidad de forma gratuita (no podía ser menos), ha de procurarse el siempre excitado usuario para poder suscribirse a canales. El esquema práctico es bien simple: el sintonizador (tuner) es una pequeña aplicación gráfica (un canal a su vez, como más adelante veremos) que nos proporciona información sobre distintos emisores existentes (tal información será actualizada al actualizarse el canal que representa al sintonizador), de manera que, al conectarnos a cualquiera de ellos aparecen en pantalla distintos nombres de canales asociados a tal transmisor, acompañados de una breve descripción explicativa del tipo: “fabuloso juego de crucigramas” o “catálogo de applets”. Es decisión entonces del usuario suscribirse o no a uno de los canales mostrados. Si, por ejemplo, nos suscribimos al adictivo juego “SameGame” en el transmisor “trans.marimba.com”, el sintonizador comprobará primero si ya existía una suscripción a tal canal, y en caso negativo añadira el canal a la lista de canales suscritos para ese transmisor y requerirá al transmisor la descarga del código completo de tal canal.
En realidad un canal no es sino una jerarquía de directorios rellena de ficheros, de forma que lo que ocurre tras la suscripción es que se inicia un proceso de transferencia de tal estructura de directorios al disco duro donde está situado el sintonizador. “¡Diantre! ¿Al disco duro? -oigo bramar al lector- Pero … eso supone que este esquema no puede trabajar con NCs, y entonces Java …”. Pues, debo aclarar, la verdad es que … el lector tiene razón, otra vez. Pero ya nos ocuparemos después de este asunto. Decía que un conjunto de ficheros (código Java, ficheros de datos, etc.) va a copiarse, a la velocidad en vigor en la red, en el disco duro para inmediatamente después ejecutarse. Y es que, a diferencia de los applets y, en general, de los sistemas de componentes afectos a los paginadores, los canales no necesitan para su ejecución de contenedores específicos, de forma que terminada la descarga de ficheros aparecerá en el escritorio una ventana conteniendo el juego en cuestión. A la vez, el estado del canal pasará a ser de ejecución (“running”) en el sintonizador. Lo cierto es que parece que, de nuevo, se obliga al usuario a pasar por la penosa y dilatada labor de transferir ficheros por Internet, pero piense el contrito lector (y aquí se muestra un nicho de mercado) que la fuerza de los canales está en sus capacitaciones de rápida actualización y control de seguridad, de forma que quizá en breve veamos cómo se distribuyen discos compactos con primeras versiones de canales que podrán ser copiadas de forma más eficiente a nuestro disco duro tras su comparación ineludible con el canal equivalente provisto por cualquiera de los transmisores sugeridos en el mismo proceso de instalación (como el lector podrá fácilmente adivinar, la mera copia de ficheros del CD al disco duro obviaría la necesaria conexión con el transmisor e impediría el normal funcionamiento del esquema de sintonización). Pero volvamos a nuestro juego: decíamos [5] que los ficheros constitutivos del programa-canal se almacenan en disco, pero … ¿no ocurre lo mismo con los applets, que se guardan en el caché de los paginadores? ¡Claro que no! El caché es un sistema de antememoria destinado a optimizar la carga de recursos, de forma que no asegura la integridad referencial, respecto de tal caché, de un conjunto lógico de ficheros, mientras que un canal mantiene una estructura completa de ficheros que sirve de soporte para la ejecución del aplicativo asociado en cualquier momento, se esté conectado a Internet o no. Naturalmente la invocación siempre se realiza mediante el sintonizador, que finalmente es quién determina y controla la zona del disco cliente en que se almacena cada canal. Esto supone que la estructura de directorios de los canales no ha sido pensada para su uso directo por el usuario final, sino más bien como un espacio de seguridad monitorizado por el par transmisor-sintonizador. CONTINUARÁ … penas hemos empezado y ya se agolpan las preguntas: ¿Cómo puedo transmitir canales? ¿Se pueden transmitir applets como canales? ¿Son los canales un medio idóneo para el alquiler de software? ¿Podría, en tal caso, el propietario del software borrar la aplicación de mi disco duro en caso de impago? ¿Dónde podré encontrar un canal de abogados virtuales para defenderme? ¿Existen chistes de abogados virtuales? … En fin, las cuestiones son muchas y todavía queda mucho que decir sobre la estructura técnica de Castanet y de su interacción con Bongo. Pero esto será en el próximo artículo. [1] Quien no aprecie la esencial relación entre los conceptos descritos debiera leer “Diferencia y Repetición” del nietzscheano Gilles Deleuze. [2] Resulta divertido constatar que en la mayoría de textos informáticos el calificativo “normal” se aplica a sujetos con escaso o ningún conocimiento técnico y capacidades por debajo de la media. Nada en mi ánimo, empero. [3] De hecho las páginas web masculinas han sustituido al coche como símbolo fálico en Internet. Los resultados, como en la vida real, son igual de deprimentes e … insignificantes. [4] El acento es parte de la grafía publicitaria, pero no del nombre inglés. “Tecnología con sabor hispano”, dicen algunos estúpidos comentaristas gringos. [5] Al usar el plural sostengo la ilusión que lectores y autor navegan por el mismo discurso. “¡Oh hipócrita lector, mi semejante, mi hermano!” creo recordar que mentaba Baudelaire. |
|||
| Pº. Castellana 188, 14º e · 28046 - Madrid · info@a4devis.com |
|||