          WWWOFFLE - World Wide Web Offline Explorer - Version 2.4a
          =========================================================


QU?
-----

El formato del cach que utiliza WWWOFFLE para almacenar las pginas
web ha cambiado desde la versin 2.x en comparacin con versiones 
anteriores. Si ha usado la versin 1.x *DEBE* actualizar el cach
existente antes de poder usar esta nueva versin.


CMO?
-----

         *** LEA TODA ESTA SECCIN ANTES DE HACER NADA MS ***


Cuando compila WWWOFFLE tambin se compila otro programa llamado 
'upgrade-cache'. Necesita ejecutar este programa para convertir el
cach del viejo formato al nuevo.


Hay varias formas de hacer la conversin, lo siguiente se aplica para 
todas ellas.

En cada una de las formas usted debe ejecutar el programa 'upgrade-cache'
con el directorio almacn como argumento (normalmente 
/var/spool/wwwoffle). Cuando el programa se ejecute imprimir en
pantalla informacin y mensajes de advertencia que pueden ser tiles.


Opcin 1 - Sea temerario

Ejecute 'upgrade-cache /var/spool/wwwoffle', mire los mensajes que
aparecen en pantalla y rece para que funcione.

Opcin 2 - Sea valiente

Con sh/bash ejecute 'upgrade-cache /var/spool/wwwoffle > upgrade.log 2>&1'
o con csh/tcsh run 'upgrade-cache /var/spool/wwwoffle >& upgrade.log'
lea los mensajes y compruebe las advertencias.

Opcin 3 - Sea seguro

Haga copia de seguridad del cach primero, luego siga con la opcin 2.
Con GNU tar sugiero que use la opcin --atime-preserve para que el tiempo
de acceso de los ficheros en el cach no se modifique al hacer la copia.
Los ndices y la opcin de purga en WWWOFFLE usan este parmetro, por lo
que es importante.


Cuando termine, los directorios de huspedes mltiples en
/var/spool/wwwoffle se habrn movido a un nuevo subdirectorio llamado
http.
El directorio outgoing y el directorio http son los nicos que deben quedar.

Si hay algn mensaje de advertencia, debe decidir que necesita hacer.
Puede ser por una de las siguientes razones.

Que se haya ejecutado upgrade-cache por un usuario que no tiene
permisos de escritura.
Que se cambiaran uno o ms ficheros mientras se ejecutaba el programa.
Que haya un fichero de sobra en uno de los directorios que necesitan
borrarse.
Que haya un enlace simblico que no apunte a ningn sitio.


Si el programa upgrade-cache falla, puede haber un fallo - comunquemelo.

Si le quedan muchos ficheros o directorios y las advertencias no son
claras puede haber un fallo - comunquemelo.

Si solo hay un pequeo nmero de ficheros o quedan ficheros sueltos o
directorios solamente brrelos, probablemente no notar que faltan.

PORQU?
--------

El esquema existente para el nombre de los ficheros en el cach tiene
algunos problemas, el nuevo es mejor.

0) Fue diseado para mi uso personal por lo que no necesitaba muchas
   pginas almacenadas y no visitaba pginas con nombres raros.
   Puede pensar que los parches que implement para que funcionara no eran
   lo suficientemente buenos, pero en la poca que los escrib lo quera
   funcionando lo ms rpido posible y no los escrib pensando en un
   desarrollo futuro. Personalmente, el esquema que implement 
   anteriormente no me ha causado problemas.

1) Era posible que para una pgina web los argumentos se almacenaran
   incorrectamente. Para cada pgina se calcula un valor de 'hash' para
   encontrar un nombre de fichero nico. La razn de que esto fallara es
   que us una funcin de hash que hice en el momento, dando un valor de
   32 bits. Esto pareca suficiente para 4000 millones de pginas en misma
   combinacin de camino y husped. Pero result que la funcin no era lo
   suficientemente buena y las posibilidades eran menores.

2) No haba previsin para ningn protocolo aparte de http. La idea
   de hacer ftp se me vino a la cabeza rpidamente pero no se poda
   implementar fcilmente con el esquema anterior.

3) El directorio de salidas era ineficiente para un nmero grande de
   ficheros. Incrementando la secuencia de nmeros resultaba en un acceso
   lento. Esto se arregl en la versin 1.2.x pero todava no poda haber
   muchas peticiones para la misma URL en el directorio. Ahora se usa un
   nombre nico en una funcin 'hash', de esta forma se almacena una sola
   peticin para cada pgina.

4) Caracteres errneos y URLs codificadas causaban problemas.
   Alguna URLs que tenan caracteres extraos incluyendo secuencias
   codificadas causaban problemas. La URL http://www.foo.com/~bar y la URL
   http://www.foo.com/%7Ebar son la misma URL pero se podan almacenar
   en diferentes ficheros.

5) Ahora hay un mejor diseo sin casos especiales.
   Anteriormente solo los ficheros con argumentos necesitaban 'hashing',
   ahora todos lo usan, simplificndose la lgica del programa.
   El formato del directorio saliente es el mismo que el del resto de
   los directorios.

6) Hay ms posibilidades para una futura expansin.
   Se puede considerar el aadir ms ficheros al cach para almacenar
   informacin extra acerca de la URL, por ejemplo una contrasea.
   Es obvio que sera otro fichero con el mismo valor de 'hash' pero
   diferente prefijo.

