Ya nos estamos acostumbrando a hacer una reseña periódica sobre el estado en que se encuentran los visores para Second Life y Opensim, en la cual, detallamos aquellas novedades importantes para el futuro de los mismos y que se puede esperar a corto o mediano plazo.
La gran novedad, podríamos decir, viene del lado del Proyecto Imprudence/Kokua, el cual, luego de un buen tiempo de estar alertagado ha retomado impulso, pero luego de un par de reuniones de los desarrolladores y usuarios en las cuales se han tomado decisiones importantes.
Por lo pronto, se ha decidido no trabajar mas en el visor Imprudence, ya que se cree que, asi como está, es apto para ser utilizado en Opensim y no amerita esfuerzos para adaptarlo a los requerimientos de Second Life.
En cambio, el proyecto se centrará en el desarrollo de Kokua (basado en el código del visor 2/3 de Linden Lab) para su utilización tanto en Second Life como en OpenSim. Vale aclarar que en una vieja alpha de este visor he podido notar que, si bien, su código es el de Snowstorm, han hecho un trabajo excepcional al modificar la UI casi completamente para que ésta se pareciera en un 90% a la del Visor 1. En este sentido, creo que la UI de Kokua es, lejos, la que mas parecida es a la del V1. Veremos como deriva cuando le incorporen el código del V3 y su FUI (Flexible User Interface).
Por último, el desarrollo de Kokua se centrará en desarrollar versiones del visor para las plataformas Windows de 32 bits y Linux y de 32 y 64 bits. Lamentablemente, por falta de disponibilidad de medios se suspende el desarrollo de la versión para MAC.
Por otro lado, quiero hacer un breve comentario sobre el desarrollo del Visor Nirans, el cual avanza a grandes pasos y con actualizaciones constantes. No obstante, he podido notar que su desarrollo está fuertemente atado a los vaivenes emocionales de su desarrollador, Niranv Dean, ya sea sus desengaños amorosos que provocaron un período de estancamiento a fin de año, como su pelea, en estos días, con quien compilaba las versiones para linux, provocando que éste se aleje del proyecto y rompa una relación de amistad. Si bien, Nirans apunta a ser un visor interesante y avanzado, esperemos que estos vaivenes personales no terminen perjudicando su desarrollo y futuro.
Por el lado de Singularity, si bien está muy silencioso, Siana y su equipo están trabajando a destajo para liberar en breve una nueva versión (sería la 1.6.1) y tienen en carpeta varias ideas interesantes. Siana esta interesada en liberar una versión estable y mejorada de la actual, corrigiendo los fallos actuales, dándole mayor estabilidad al visor y haciéndolo mucho más confiable (de hecho hoy ya es muy confiable). Luego de logrado esto, se comenzará a trabajar en incorporarle mas funciones y características, como ser, múltiples capas alpha, migrar a los perfiles web y otras mas.
También, se ha decidido comenzar a trabajar en una versión de Singularity para la plataforma de Linux 64 bits, con lo cual, seremos muchos los agradecidos por esto. Además, trabajando a destajo, espero llegar a tiempo para el lanzamiento de la nueva versión y que ésta incorpore el idioma Castellano en su interface, algo muy solicitado por la comunidad de habla hispana, que va en crecimiento con este visor, y en lo cual, con el visto bueno de Siana, me encuentro trabajando.
Por último, para este visor, en una charla informal que tuve días pasados con Siana, me reiteró su compromiso de mantener en Singularity la interface del Visor 1 «hasta el final». Incluso, lo que se decía tiempo atrás al respecto, fue confirmado por ella, en cuanto a que Singularity (y Cool VL) han migrado todo su código interno al del visor 2, utilizando sus APIs, pero manteniendo la UI del Visor 1, por lo cual, cualquier cambio que Linden Lab realice en el código de su visor puede ser adaptado con el mínimo esfuerzo por singularity.
He dejado para el final el proyecto Phoenix/Firestorm, el cual, me presenta un panorama complicado de analizar, dadas las variantes y realidades que presenta el mismo. Por un lado, estos últimos días arrecian las consultas de usuarios con problemas graves en el uso del visor Phoenix (aclaro que yo utilizo Phoenix bajo Linux y salvo un mínimo problema gráfico, no padezco lo que veo en los usuarios de windows) y a los cuales, luego de brindarles, el soporte oficial, algunos consejos básicos de compromiso, terminan «sugiriendo» que se pasen a Firestorm «porque es mucho mejor». Podría llegar a creer que esto es así, pero los problemas que vi y los argumentos técnicos dados para justificar la migración no quedan claros, ya que si fuera como dicen, el mismo problema se experimentaría en los visores Singularity y Cool VL y, por el contrario, muchos usuarios han terminado migrando a éstos (especialmente Singularity) y han terminado resolviendo sus problemas.
Por otro lado, el pasado 22 de enero, publicaron un post en su blog oficial con el título «¿Hemos estado quietos de nuevo?» y en el explican los motivos de esa quietud y los planes a futuro del proyecto, tanto para Phoenix como para Firestorm. Este post deja mucha tela para cortar y puntos para analizar detenidamente.
Firestorm: Se dice que estuvieron trabajando intensamente en la nueva versión de mantenimiento (cosa que seguramente es cierta), la cual, mas que versión de mantenimiento será una nueva versión. Corrección de muchos fallos, errores, mejora de funcionalidades, etc. Incorporación del Código del V3 y su FUI (Flexible User Inteface), lo que provocó que muchas partes del código de Firestorm se «rompieran», lo cual es lógico.
Tampoco se puede ver algún comentario o informe sobre si la nueva versión de este visor soportará el Mesh Deformer de Qarl o no. Imagino que si soportará el parche de inventario de Linden Lab, ya que está incoporado en el código del Visor 3, pero nunca se sabe. Quizás estén esperando a ver que decisión toma Linden Lab al respecto para actuar en sintonía con la empresa, realmente no lo se, pero si me sorprende que FireStorm sea el único visor de la serie 2/3 que no se haya preocupado por esta importante característica.
Ahora bien, en estas últimas semanas, si uno se da una vuelta por el grupo de soporte en inglés del Visor, podrá ver que los miembros del equipo ostentan tags de sus respectivas versiones del visor, como ser «FS 3.3.7, FS4.0.1, etc.», lo que implica que, desde la última versión pública 3.2.2, se han desarrollado muchas otras mas, para uso interno y QA (Control de Calidad) pero que nunca verán la luz pública, entonces se da el caso que mientras un usuario tiene problemas con la versión pública actual, recibe soporte de alguien que utiliza una versión mucho mas nueva y con muchos fallos corregidos, lo cual produce un desfazaje en lo que experimentan unos y otros. Creo que aquí, todo ese tiempo que se están tomando entre versiones públicas (usado para versiones internas) redunda en un perjuicio al usuario que debe lidiar con fallos conocidos y ya solucionados pero que no se aplican públicamente. He notado que esto provoca que varios usuarios decidan migrar a otros visores.
Phoenix: Aquí, el tema se plantea de otra manera. Ahora se descubre que Linden Lab ha «flexibilizado» su política contra el V1 y se estima que ya no desaparecerá el soporte de APIs a corto plazo (¿Dónde quedó el discurso apocalíptico del fin del V1?) por lo cual, se renueva el compromiso de seguir manteniéndolo en la media que puedan y en el transcurso de «los próximos meses» se liberará una nueva versión corrigiendo la infinidad de errores que tiene. Vale aclarar que si uno se remite al repositorio del código fuente de Phoenix, podrá ver que el mismo no se toca desde hace 7 semanas, coincidiendo con el lanzamiento de la última versión pública, la 1.6.0.1600. Lo cual da a entender que no existe la preocupación de trabajar sobre este visor, al menos no sienten la urgencia de hacerlo. Si la táctica es «convencer» al usuario de migrar a Firestorm, no tiene sentido mejorar Phoenix.
Pero, como consecuencia de esta política he podido notar que, en el grid, ha disminuido notablemente la cantidad de uso del visor Phoenix (aunque sigue siendo el visor mas utilizado) pero esa disminución no se compensa con un aumento equivalente en el visor Firestorm, sino que se reparte entre éste y otros visores, especialmente, en Singularity, porque son muchos quienes aún se resisten a migrar a visores con la interface del V2.
SaludOS/2