Bitácora de Gesbit

Todavía guardo una "rama" de Gesbit que está actualizada completamente, salvo porque no incorpora el sistema de caché de contenidos, pero, ya me he decidido a publicar Gesbit con el mismo, hasta el punto de que todas mis bitácoras están haciendo uso del caché, no porque sea necesario (no son muchos sus visitantes) pero por probar qué tal va.

Poner en marcha el sistema de caché de contenidos es bastante sencillo, depende únicamente de una constante en el archivo de configuración de Gesbit, tal como se explica en esta página de la wiki de Gesbit. No creo que deba extenderme más sobre el asunto, sino decir que ya está disponible en Gesbit, puesto que he hablado de este tema en esta, esta y esta otras entradas de esta bitácora.

Tan sólo terminaré diciendo que, igual no lo notas, pero, es posible que esta página que lees ahora se trajese desde el caché de contenidos de la misma, con lo que su procesado fue un poco más rápido y menos costoso para el servidor. De todas formas, el uso del caché en Gesbit es opcional: no todas las bitácoras lo necesitarán, puesto que, por ejempo, las mías, funcionan muy bien sin el mismo, aunque ahora lo utilicen a modo de prueba, como digo.

He hecho bastantes pruebas, varios intentos, llevo cuatro o cinco días trabajando en este asunto, y, sin embargo, estoy seguro de que aparecerán problemas. Como he dicho ya, guardo una copia de seguridad de la rama de Gesbit que no incluye el caché de contenidos, por si las moscas, pero, espero no tener que recurrir a ella, y que, los problemas que se presenten, se dejen solucionar con más o menos trabajo. No importa. Hoy, de nuevo, creo, Gesbit es un poquito mejor.

Me apetece escribir sobre el funcionamiento del sistema de caché en Gesbit. Ni siquiera tengo claro que vaya a formar parte de Gesbit, seguimos haciendo pruebas (enlace probablemente temporal), y haciendo cambios a la clase "GbCache", que es la encargada de realizar prácticamente todo el trabajo necesario. ¿Cómo funciona el caché de Gesbit? Voy a tratar de explicarlo en esta entrada, continuación de esta y esta otra.

De entre todos los intentos de implementación, sin duda este último es en el que he llegado más lejos, y el que mejor ha salido de todos. En primer lugar hay que decir que Gesbit no delega el caché de contenido a un posible plugin. ¿Por qué razón? Porque inicializar el sistema de plugins de Gesbit tiene un coste: una consulta SQL a la base de datos, y además sería necesaria la ejecución de más código PHP del verdaderamente necesario.

Dejando a Gesbit encargado del caché conseguimos varias cosas, por lo tanto. En primer lugar, la clase "GbCache" se instancia acto seguido de las clases "Timer", "Input" y "Localize" (esta última podría evitarse, si se viera necesario). En ese punto Gesbit no ha hecho ni una sola consulta SQL a la base de datos, y la clase "GbCache" ya puede hacer su trabajo, uno de ellos: servir contenido previamente "cacheado".

En ese punto, como digo, Gesbit tampoco ha necesitado instanciar otras clases, como "GbDb", "User", "GbPlugins", "GbOptions", "DateUtils" o "Themes". De modo que no sólo nos ahorramos consultas SQL a la base de datos, sino que además nos ahorramos no poco del código PHP necesario para la inicialización y puesta en marcha de Gesbit. La clase "GbCache" se encarga de todo, de guardar contenido en caché y de recuperarlo.

¿Qué es lo que se guarda en el caché de contenido? Gesbit puede guardar en el caché de contenido todo el XHTML y el RSS que produce. La portada de la bitácora, la páginas de categorías, etiquetas o autores, el archivo, las entradas "solas", las páginas de la bitácora, eso en lo que respecta al XHTML, pero, Gesbit también guarda en el caché el RSS de todos los "feeds" que puede generar en una bitácora determinada.

Hace poco comenté en esta otra entrada, que, las páginas de Gesbit estaban siendo algo costosas, en realidad las más costosas de todas, en lo que se refiere al número de consultas SQL necesarias para su formación. Encontré la solución quitando del medio el menú de las bitácoras, el "sidebar", como se hace cuando se muestran entradas "solas", y ahora las páginas son las que menos consultas SQL requieren para su formación.

Hoy he caído en que ocurría algo similar con el script "404.php" de los temas de Gesbit. Estos mostraban el menú de la bitácora, de modo que requerían una serie de consultas, que, en verdad, pueden muy bien omitirse. Ahora estos scripts muestran lo que importa: información al usuario de que su "consulta" no ha producido resultados, posibles soluciones y un formulario de búsqueda en la bitácora, por si quiere utilizarlo.

Con esto se ahorran varias consultas SQL en este tipo de "scripts". Hay que decir, además, que este tipo de "scripts", no es "cacheado" nunca por el sistema de caché de Gesbit (si es que este llega a buen puerto, ya sabes que todavía sigo trabajando en ello) de modo que este ahorro se producirá en todo caso. Respecto del caché de Gesbit, ahora mismo en preparación, creo que va por buen camino, pero, seguiré informando en su momento.

Sigo con el asunto de implementar un posible sistema de caché en Gesbit. Está resultando de lo más interesante, en particular, porque, si no me equivoco, este es el típico caso en que no se puede lograr, es imposible conseguir una solución cien por cien perfecta, si es que podemos asumir que en algunas tareas, sí que podemos lograr cierta perfección. Pues bien, con este asunto del caché de contenido, hasta dondo estoy viendo, y hasta donde estoy llegando, no se puede sino llegar a una especie de "acuerdo" entre lo que se puede hacer y lo que no se puede hacer.

No digo que otra persona no viera más allá que yo, estoy seguro de que así será, pero, en lo que a mí respecta, estoy empezando a asumir que el sistema de caché no será perfecto, pero, por lo menos, servirá en bastantes ocasiones. Creo que es bastante resumir todo este misterio en una pregunta: ¿Qué ocurre cuando se borra una entrada de una bitácora? La respuesta obvia es: habrá que borrar esa entrada del caché de contenidos. Lo imperfecto llega cuando a la pregunta anterior se suma la siguiente, ¿y qué pasa con las páginas que pueden seguir mostrando esa entrada después incluso de borrarla?

Dicho de otro modo, por si no se me ha entendido, Gesbit puede "servir" una página correspondiente a cierta etiqueta X. Dicha página mostrará la entrada Y, porque la entrada Y se guarda bajo la misma etiqueta X. Así que guardamos en el caché la página de la etiqueta X, pero, luego borramos la entrada Y... ¿qué hay de la página de la etiqueta X que guardamos en el caché? Porque esta contendrá la entrada Y, pero, esta entrada ya ha sido borrada de la bitácora. Ahora bien, téngase en cuenta que hablamos de etiquetas, pero, igual podríamos hablar de categorías, porque ocurre el mismo caso.

Y también de las búsquedas, del archivo por fechas, de los RSS, etc., etc. Todo está relacionado. Si se borra una etiqueta, por ejemplo, y no se borra la entrada que contiene esa etiqueta, el caché de la página que muestra la entrada, mostrará la etiqueta, que ya no existe. Y este asunto no tiene fácil solución. No tiene, de hecho, una solución. Porque podríamos intentar ser tajantes y razonar: "Si se actualiza una entrada, etiqueta, categoría, autor, lo que sea... se borra todo el contenido del caché.". Efectivamente, así acabaríamos de golpe con los problemas, pero, ¿para que serviría un caché que se borraría entero cada vez que alguien añada un comentario a la bitácora, por ejemplo?

Aún así, se podría decir: "Todavía serviría el caché, porque, aunque fuera durante el tiempo en que "nada cambia" en la bitácora, se estaría utilizando el caché.". Y es cierto. Pero, si no queremos ser tajantes, si no queremos tomar una decisión como esta, entonces tendremos que llegar a un acuerdo, asumir ciertos "costes", y guardarnos las espaldas. ¿Cómo haremos todo esto? Pues, por ejemplo, cuando se borra una etiqueta, podemos borrar las páginas correspondientes a esa etiqueta, pero, no borrar todo lo demás. "¿Cömo? Pero, si hacemos esto, sería posible que una entrada se mostrase desde el caché de contenido, y mostrase que se guarda bajo una etiqueta, que, en realidad, ya no existe.".

Así es. Pero, ¿qué se puede hacer? Es un costo que hay que medir, hay que ver hasta qué punto es asumible que algo así ocurra, y si merece la pena que algo así pueda ocurrir, con el fin de mantener en el caché el máximo contenido posible. Ahora bien, al final tendremos guardadas las espaldas. ¿De qué manera? Porque el caché de contenido tiene una tiempo de expiración. Es decir, el contenido guardado en el caché es borrado del mismo una vez excedido el tiempo máximo de expiración. ¿Cuál es este tiempo máximo? Podría ser una hora, dos horas, tres horas... Pero no podría ser mucho más tiempo, y hasta es posible que la cifra dependa del "tráfico" de una determinada bitácora.

Por ejemplo, en una bitácora que se actualizara a menudo, el caché podría terminar con demasiado contenido obsoleto, si el tiempo de expiración es demasiado grande. El tiempo de expiración, por decirlo así, es una especie de salvaguarda, que, por ejemplo, cada hora, asegura que el caché se renueva completamente. Y, en fin, en estas estoy. Viendo qué borrar y qué no borrar en según qué situaciones. Por lo demás todo parece funcionar razonablemente bien: el contenido, cuando se sirve desde el caché, no ha necesitado previamente de consulta SQL alguna a la base de datos. Seguiré dándole vueltas al asunto y veremos en qué queda.

Si a alguno de vosotros, lectores pocos, y menos comentadores, de esta bitácora, se os ocurre alguna idea o sugerencia relacionada con todo esto de que vengo hablando, huelga decir que esta será bienvenida y agradecida como se debe. :P

Sigo liado con el asunto del caché en Gesbit, no te lo pierdas. Llevo, de hecho, un par de días, trabajando exclusivamente en este asunto. Después de varios intentos, como ya comenté, este parece ser el más "fuerte". Y todavía hay bastantes cosas que se me escapan... sólo que se me ha metido en la cabeza que es hacedero y buena cosa. Entretanto, como suele ser habitual, voy arreglando y optimizando algunas cosas. Una de ellas ha sido el coste de las páginas en Gesbit.

Como sabes, una bitácora tiene, además de entradas, que forman parte de la cronología de la bitácora, también páginas, que están fuera de la cronología de la bitácora, que van un poco "a su aire". Pues bien, mira tú por dónde, ayer descubrí que Gesbit necesitaba 17 consultas SQL para conformar la página de una bitácora. Enseguida pensé que algo iba mal, que había algún error ahí, puesto que, para la portada de una bitácora, Gesbit necesita de 12 consultas SQL, por ejemplo.

Efectivamente, no es que fuera nada mal. Pero, en los temas de Gesbit estaba mostrándose, en las páginas, también el menú de la bitácora o "sidebar". Esto no se hace así cuando se muestran entradas "solas", y de hecho para conformar una entrada "sola" Gesbit precisa de 10 consultas SQL. Así que era eso, sumar a las consultas necesarias para conformar las páginas, las necesarias para conformar el menú de la bitácora, hasta que se sobrepasaba la marca de Gesbit en cuando a consultas SQL para conformar su contenido: nada menos que 17 consultas SQL.

Esto ya está arreglado, dada además mi obsesión por estas cuestiones. Actualmente, Gesbit no muestra el menú de la bitácora en las páginas, de modo que ahora son sólo necesarias 8 consultas SQL para conformar las páginas de una bitácora. Sólo el número de consultas puede hacer pensar que el menú estaba demás en las páginas, dado su costo, pero, no sé si engañado, también creo que es más o menos lógico que el menú no se muestre en las páginas: como tampoco se muestra en las entradas "solas". Quizás me engaño, ya digo, pero, así quedan las cosas, de momento.

Respecto del asunto del caché... en este penúltimo intento estoy implementándolo en el "corazón" de Gesbit. En realidad Gesbit añade una clase más, "GbCache", que es la que se encarga de realizar el trabajo necesario, básicamente. En anteriores intentos había ido más por el lado de utilizar plugins, pero, haciéndolo como ahora puede asegurarse que Gesbit no necesitará hacer ninguna consulta a la base de datos para servir contenido guardado previamente en el caché. Todavía tiene que ejecutar algo de PHP, pero, no hace ni una sola consulta SQL. Veremos en qué queda todo esto.

Sobre el caché de Gesbit lo único que se puede decir es que no existe aún. Bueno. No. En realidad se pueden decir también otras cosas, sino para qué me iba a poner a escribir esta entrada sobre el caché de Gesbit. Se puede decir que cada vez lo veo más útil, hasta el punto de haber hecho ya algún que otro intento de implementación, si se puede decir así. Iba a decir necesario en lugar de útil sólo, pero, lo cierto es que Gesbit, hasta donde yo llego, no es "pesado", y un sistema de caché vendría a ser un "por si acaso", pensando en que Gesbit gestionara bitácoras con "muchas visitas".

Como los que seguís esta bitácora ya sabéis, la portada de una bitácora en Gesbit necesita realizar sólo (creo que puedo decirlo así) 12 consultas SQL a la base de datos. Además, la mayoría de ellas son bastante sencillas, que incluso ni requieren datos. Sin embargo, un sistema de caché evitaría todavía más consultas SQL, y, en el caso de bitácoras con muchas, no sé cuántas, pero, muchas visitas, no es que piense que Gesbit vaya a ir mal, pero, un sistema de caché ayudaría al servidor, sería bien. Como ya he dicho, he hecho varios intentos, y, escribo esto por si se me ocurre algo.

Hoy he puesto en orden el archivo "gb-globals.php", donde se "inicializan" las principales "variables globales" de Gesbit. Lo he hecho pensando en que el caché de Gesbit se implementase por medio de un plugin, no desde el propio "corazón" de Gesbit. Y tengo algunas, muchas dudas. El archivo que he mencionado procura guardar cierto orden en la inicialización de las variables, de tal modo, que, cuando se inicializa la variable "GbPlugins" (el gestor de plugins de Gesbit) tan sólo se han realizado dos consultas SQL a la base de datos. ¿Por qué veo estas dos consultas necesarias?

Bien. La idea es la siguiente. Para actuar, para ponerse en marcha, un plugin necesita "estar activo". Una de las dos consultas, por lo tanto, es la que requiere las opciones "auto cargables" de Gesbit, y entre estas se encuentra la que especifica qué plugins están activos. La otra consulta no retorna datos: se trata de establecer en la base de datos el "charset" que se utilizará. Estas dos consultas SQL son necesarias, tal como lo veo ahora. Podría pensarse entonces qué sentido tiene el sistema de caché implementado de este modo, si, de todas formas, va a requerir consultas a la base de datos, aunque sean sólo dos.

Pero, creo que mi razonamiento no falla, dicho de otro modo, si me pregunto, ¿el plugin que implemente el sistema de caché tiene o no tiene que saber si está activo o no? Es evidente que sí. Luego, entonces, no hay más que hablar, es necesaria la consulta SQL correspondiente. Ahora bien, queda otra posibilidad: que sea el propio Gesbit quien implemente un sistema de caché. ¿Sería necesario en este caso recurrir a la base de datos? No. Puesto que Gesbit, antes de hacerlo, podría poner en marcha el sistema de caché, que comprobaría si existe el contenido que se solicita, y servirlo, directamente, sin más ni más.

Creo que hay que valorar, entonces, esta cuestión. Yo quisiera un sistema de caché que no requiera de la base de datos para funcionar. Luego entonces este sistema no podría implementarlo un plugin, si el funcionamiento de este necesita de al menos dos consultas SQL a la base de datos. Pero integrar el sistema de caché en el propio Gesbit, aunque no me parece mal, de entrada, implica una serie de cuestiones. Por ejemplo, habría que especificar el directorio donde guardar el contenido mediante alguna constante: puesto que se trata de evitar el trato con la base de datos. Y luego estarían los correspondientes permisos...

Permisos que tendría que tener Gesbit para escribir en el directorio susomentado, manteniendo hasta ahora en Gesbit la especie de norma de que este no requiera permisos de escritura en ningún directorio del servidor. Pero está claro que algo habría que sacrificar y si es menester contar con permisos en un directorio, para guardar el contenido en "caché", así será, una excepción a la regla. Al escribir esto estoy dándole vueltas al coco, y veo atractiva la posibilidad de que Gesbit implemente de suyo un sistema de caché. Ya iremos viendo en qué queda todo este asunto.

Una de las cosas que he de llevar a cabo entorno a Gesbit, es procurar estar al tanto de las actualizaciones del software que forma ya parte del propio Gesbit. Por ejemplo, en los últimos días, han aparecido hasta dos actualizaciones del editor TinyMCE, que, mayormente, solucionaban ciertos errores y, claro está, Gesbit utiliza ahora mismo la última versión de este excelente software.

A veces no basta con actualizar sin más. TinyMCE, otra vez por ejemplo, está en cierta forma "personalizado" en Gesbit, de modo que hay que tener en cuenta que estas "personalizaciones" se preserven en la actualización del software. El caso de la biblioteca jQuery para JavaScript es también similar. Hace unos días que actualizé Gesbit para que usara la última versión de jQuery, pero, todavía me quedó un pequeño detalle al hacerlo.

Y es que hoy, leyendo más detenidamente en la bitácora de jQuery, acerca de la última versión de esta fantástica biblioteca, me percato de que cierto plugin para jQuery, ha sido incluido en el "core" (corazón) de la biblioteca, de modo que todo aquel que lo estuviera utilizando, puede dejar de hacerlo. Me he acordado de que uno de los plugins de jQuery que se usan en Gesbit, necesitaba a su vez del plugin que ahora está incluido en jQuery.

De modo que acto seguido he borrado de la distribución de Gesbit el mencionado plugin, y, efectivamente, he comprobado que todo sigue funcionando tal como se espera. Acto seguido he actualizado Gesbit y las bitácoras en que lo utilizo. Y todo esto me ha hecho pensar en la importancia de estar encima de un proyecto como Gesbit, pues, en poco tiempo, este puede quedar "desmadejado", por decirlo así, usando software obsoleto y hasta con errores.

Bueno. Es una reflexión al respecto. En todo caso es de muy agradecer poder contar con software como jQuery y TinyMCE, entre otro estupendo software de que hago uso en Gesbit. De ahí, precisamente, el apartado "Acerca de..." en Gesbit, agradeciendo a todos los autores por su inestimable trabajo, sin el que Gesbit no sería ni podría ser lo que es. Además es muy agradable saber que Gesbit se beneficia también de las mejoras en el software de terceros que utiliza.

Gracias a que tengo abierto el entorno con el que trabajo con Gesbit, prácticamente, todo el día, puedo toparme con código fuente que a veces me deja perplejo, que no me explico cómo pudo llegar ahí, si es que no era más o menos sencillo darse cuenta de lo "evidente". Y entrecomillo evidente, porque, juro que he pasado por este método mil veces, por lo menos, y hasta hoy no he caído de su absurda implementación. Fíjate, fíjate:

  public function GetBlogOption($optionName, $defaultValue = ''){
    $d = $defaultValue;
    switch($optionName){     
      case GBOPT_BLOG_NAME:
        return $this->GetOptionValue(GBOPT_BLOG_NAME, $d);
        break;
      case GBOPT_BLOG_THEME:
        return $this->GetOptionValue(GBOPT_BLOG_THEME, $d);
        break;
      case GBOPT_ACTIVE_PLUGINS:
        return $this->GetOptionValue(GBOPT_ACTIVE_PLUGINS, $d);
        break;
      case GBOPT_POSTS_PER_PAGE:
        return $this->GetOptionValue(GBOPT_POSTS_PER_PAGE, $d);
        break;
      case GBOPT_POSTS_IN_FEEDS:
        return $this->GetOptionValue(GBOPT_POSTS_IN_FEEDS, $d);
        break;
      case GBOPT_BLOG_DESCRIPTION:
        return $this->GetOptionValue(GBOPT_BLOG_DESCRIPTION, $d);
        break;
      case GBOPT_USE_UPDATE_PINGS:
        return $this->GetOptionValue(GBOPT_USE_UPDATE_PINGS, $d);
        break;        
      case GBOPT_UPDATE_PING_URLS:
        return $this->GetOptionValue(GBOPT_UPDATE_PING_URLS, $d);
        break;
      case GBOPT_COMMENTS_PER_PAGE:
        return $this->GetOptionValue(GBOPT_COMMENTS_PER_PAGE, $d);
        break;        
      case GBOPT_ACCEPT_TRACKBACKS:
        return $this->GetOptionValue(GBOPT_ACCEPT_TRACKBACKS, $d);
        break;                
      case GBOPT_BLOG_METAKEYWORDS:
        return $this->GetOptionValue(GBOPT_BLOG_METAKEYWORDS, $d);
        break;
      case GBOPT_STRING_DATEFORMAT:
        return $this->GetOptionValue(GBOPT_STRING_DATEFORMAT, $d);
        break;
      case GBOPT_INSTALLED_DBVERSION:
        return $this->GetOptionValue(GBOPT_INSTALLED_DBVERSION, $d);        
        break;                   
      case GBOPT_COMMENTSFORM_CAPTCHA:
        return $this->GetOptionValue(GBOPT_COMMENTSFORM_CAPTCHA, $d);
        break;
      case GBOPT_MODERATE_NEWCOMMENTS:
        return $this->GetOptionValue(GBOPT_MODERATE_NEWCOMMENTS, $d);
        break;
      case GBOPT_ALLOWED_POST_HTMLTAGS:
        return $this->GetOptionValue(GBOPT_ALLOWED_POST_HTMLTAGS, $d);
        break;
      case GBOPT_ALLOWED_COMMENT_HTMLTAGS:
        return $this->GetOptionValue(GBOPT_ALLOWED_COMMENT_HTMLTAGS, $d);
        break;
      default:
        return $d;
        break;
    }
  }

Ese "pomposo" método, en realidad, a poco que uno se fija, puede resumirse, justamente, en lo siguiente:

  public function GetBlogOption($optionName, $defaultValue = ''){
    return $this->GetOptionValue($optionName, $defaultValue);
  }

Espero que no se den muchos casos de estos en Gesbit, puesto que, aunque el método cumplía con su función, lo cierto es que la implementación del mismo es del todo absurda. Salvo que haya algo por ahí que ahora se me escape. Quizás en su día sí que tenía algún sentido, pero, desde luego hoy no lo tiene, o no se le ve sentido por ningún lado. En fin. Ya está "corregido".

Preparé ayer para Iván, un compañero del ClubDelphi, que se ha ofrecido a traducir Gesbit al galego, una especie de documento en donde trataba de dar una serie de instrucciones, precisamente, para las personas interesadas en traducir Gesbit a otro idioma. Ya existía una página en la wiki de Gesbit dedicada a la traducción de temas y plugins para Gesbit, pero, el texto está más bien orientado a desarrolladores.

Sin embargo, en esta nueva página de la wiki de Gesbit, he copiado el documento al que he referido al principio, que, parece que no ha quedado del todo mal, y, esta vez está más bien enfocado a personas con ciertos conocimientos de informática, pero, que, no necesitan meter mano al código fuente de Gesbit, sino que trabajarían con el programa PO Edit, básicamente. No sé, échale un vistazo si es que te interesa algo.

Si es que estás interesado en traducir Gesbit a otro idioma, claro está. ;)

Acaso no notarás el cambio, pero, al final, después de dos días de implementación y pruebas, Gesbit guardará sus opciones "autocargables" en un solo registro de la tabla "options" de la base de datos. Esto es de lo que hablaba en esta otra entrada, bastante extensa, por cierto. Por lo tanto, para componer esta página que ves ahora, Gesbit ha requerido 16 filas menos de la tabla "options", puesto que Gesbit cuenta, actualmente, con 17 opciones. Además, cuando se añadan más opciones de este tipo, la misma consulta SQL las traerá de la base de datos, en una única fila.

He editado la página de la wiki que se dedica al asunto de los plugins que necesiten guardar sus propias opciones en la base de datos. Esto es porque los plugins pueden aprovecharse ahora de nuevos métodos y características en la clase "GbPlugin", de la que heredan, de modo que también ellos guarden, sencillamente, sus opciones en una sola fila de la tabla "options". El propio Gesbit se encargará de borrar dicha fila si el plugin se "desactiva" o desinstala.

Además, en los dos días en que he estado desarrollando todo este asunto, he descubierto algunos errores en Gesbit, no demasiado graves, pero, que, he aprovechado para corregir. Si te interesa, puedes echar un vistazo al historial de Gesbit, incluido en la distribución de su código fuente. Por ejemplo, desde los tiempos en que Gesbit era todavía "SMC" (por Simple Manegador de Contenidos), venía arrastrando una serie de identificadores en su código fuente de que comenzaban o incluían la palabra "Site". En lugar de esta palabra se han cambiado estos identificadores por la palabra "Blog", más apropiada.

Estoy muy contento, sobre todo en lo que concierne a cómo se guardan ahora las opciones de Gesbit, así como de los plugins que lo necesiten, porque, esto significa que Gesbit ha mejorado su rendimiento, aunque sea en unos prácticamente inapreciables milisegundos. Y, cuando no, este nuevo sistema se ve más prometedor de cara al futuro, es decir, pienso, aunque pueda estar equivocado, que este sistema "escala" mejor, a la hora de que Gesbit cuente con más opciones, y pueda hacer uso de más plugins.

Como siempre que hago este tipo de cambios (no es nada habitual) estoy un poco con la mosca detrás de la oreja. He probado y requeteprobado, pero, es posible que se me escape algo que no he sido capaz de ver. Ahora bien, me he decidido a actualizar Gesbit porque, llegado a cierto punto, estoy dispuesto a tratar de solucionar los posibles problemas que surgieran a raíz de estos cambios, pero, conservando el objetivo de los mismos, porque lo considero un buen objetivo, una buena cosa para Gesbit y las bitácoras que puede gestionar.

Por el momento, mis tres bitácoras ya usan la última versión (actualización, en realidad) de Gesbit y todo parece ir bien. Lo que me preocupa es que, a este paso, Gesbit va a permanecer en estado "beta" mucho tiempo aún. Porque, de haber hecho estos cambios con una versión estable, me hubiera costado implementar un "parche de actualización" para la base de datos. La estructura no ha cambiado, pero sí datos fundamentales: nada menos que las opciones de Gesbit.

Y, aunque Gesbit ya piensa en la posible actualización de su base de datos, es precisamente este asunto, entre otros, el que me lleva a retrasar una versión estable de Gesbit, una versión de la que pueda garantizarse compatibilidad con futuras versiones. Algún día tendrá que llegar esto, y, a mí me gustaría que no tardase demasiado, pero, en todo caso, visto que acabo de hacer y presentar estos últimos cambios, vamos a dejar pasar un poco de tiempo más, a ver cómo se desarrolla todo.