[Grey-Walter] (pr:topact) resumen 1

[Pablo]

respecto al correo largo que envié, aquí respondo a una respuesta que 
me ha llegado al privado.

On Thursday 11 December 2003 22:32, you wrote:
> Buenas:
>
> Antes de nada decir que tu propuesta me parece más que correcta,

bien!

> asi que solo voy a abrir esta boocota que tengo para dar una
> opinion de como pudieran hacerse las cosas.
>
> 1- Lo más importante a la hora de definir un proyecto como este es
> soñar hasta donde se quiere llegar para ver como de hondos hay que
> cavar los cimientos. Yo apostaria por hacer el google de las webs
> indy, pero tb tengo que reconocer que no tengo conocimiento ;-)

yo de conocimientos ando escaso y de tiempo más (esto como todos)
pero bueno, por soñar que no quede

>
> 2- Respecto a la separacion del desarrollo en tres módulos tirando
> a independientes, me parece correctisimo:
>
> Obtencion-> Almacenamiento -> Analisis
>
> 2.1- Para la obtención de datos yo usaria lo siguiente:
>      -Una tabla donde tendría metida una serie de "semillas" donde
> empezaría la labor de obtención de paginas. Esas semillas podría
> ser para empezar el home de sindominio.
>      -Con cada una de las semillas correria una araña para obtener
> datos. Creo que wget bastaria para esta labor. Se podría hacer algo
> más adelante de ser necesario, aunque no lo creo.

o httrack que proponían por ahí, que parece que está mejor (aún no lo 
conozco)

>      -Replicar esta información en cada uno de los clientes me
> paece villano. Además podría engordar las estadisticas de visitas
> de las paginas.

Mi idea era que la interfaz de obtención obtuviese un link (la 
primera vez desde la línea de argumentos o el fichero de 
configuración) desde la base de datos y lo dejase "bloqueado" hasta 
que ese enlace esté analizado, una vez analizado los nuevos links 
encontrados se subirían a la BD y la entrada de la BD correspondiente 
a ese link que se ha trabajado se actualizaría (se desbloquearía), de 
forma que la fecha (y hora) de la última revisión de ese link 
quedaría renovada y así se podría comprobar si hace mucho o poco que 
se ha revisado tal link y por tanto, si se debe volver a revisar, si 
tiene menos prioridad que otros links para ser procesado o si se debe 
dejar por completo.

Las entradas en la base de datos tendrían estos campos:
-URL del link (array de caracteres de qué longitud?)
-Título del link (array de caracteres de qué longitud?)
-Fecha (y hora, formato time(2) si os parece) primer encuentro con la 
página
-Fecha último encuentro
-Bloqueada-> Un bit que indique si la entrada está bloqueda o 
no.Quizá debiera ir acompañado de un "timestamp" que marque cuándo se 
bloqueó, para que se pueda desbloquear, si por "fallo" el bloqueante 
se olvida de desbloquear.
-Páginas enlazadas-> referencia a otras entradas de la base de datos, 
esta lista será de longitud variabley cada entrada de qué tipo será? 
una hash de la otra entrada? la posic. en la BD? la URL?

>
> 2.2- Para el almacenamiento usaria lo siguiente:
>       -Para el parseo de los ficheros las librerias del tipo
> HTMLParser portadas en python, perl, c, ... que son fáciles de usar
> y dan mucha facilidad para si se quiere crecer en el futuro.

el único inconveniente que le veo a estas librerías es que (creo) no 
ofrecen la misma velocidad ni potencia que un motor como mysql. 
Pueden ser útiles para procesar ficheros de configuración o generar 
informes, pero no para almacenar la BD.

>       -Para reconocer el idioma en el que esta escrita la pagina
> haría una primera pasada parseando todas las palabras de texto
> (facil con el parser y una expresion regular) y luego buscaría las
> palabras en diccionarios del iispell. Para almacenar los
> diccionarios usaria un arbol binario en memoria en vez de una base
> de datos.

El tema del reconocimiento del idioma deberíamos de tratarlo aparte, 
quizá como otro proyecto (o como un reto, para ir empezando). He 
pensado en procedimientos estadísticos: palabras que más se repiten, 
letras "extrañas" (la ñ, las ä's, ó's,ç), grupos de letras más 
repetidos (ck, sch, mp, mb), relación vocales/consonantes, etc..
Lo de ispell es buena idea, lo único es que requieres un diccionario 
por cada idioma y buscar en él (qué velocidad tiene ispell?).
Por análisis estadístico yo creo que con almacenar en un fichero (una 
especie de BD) el nombre del idioma y los resultados de las 
estadísticas aplicadas a textos (qué tipo de textos?) en ese idioma 
vale. Luego, dado un texto se le hacen las estadísticas y se le 
asigna el idioma cuyas estadísticas más se parezcan a las del texto 
dado (dentro de unos límites que si son sobrepasados concluyen en que 
el texto está en un idioma que no aparece en la BD). ¿Qué pasaría con 
los dialectos, con el slang, las faltas de ortografía, textos "multi 
idioma" (p.ej. un texto técnico en castellano con 
tecnicismos/anglicismos)?
¿Cómo funcionan los sistemas actuales de detección de idioma?

Otra cosa, hablas de un árbol binario, podrías explicar así por 
encima qué es? Aunque esté aquí organizando y desorganizando, no he 
estudiado informática, ni programación ni nada de eso. Sé programar, 
principalmente en C, tb. sé algo de redes, sistemas operativos, etc. 
pero no he pasado por ningún aula de informática y por eso éstos 
conceptos de programación teórica (estructuras de datos: pilas, 
listas, colas, árboles, etc.) no los conozco, aunque algo he oído de 
ellos.

>       -Mientras he buscado las palabras tb me he podido quedar con
> los enlaces que al fin y al cabo es lo que interesa y lo podría
> guardar en una base de datos.

ok, esto ya lo traté arriba

>       -En un futuro se puede almacenar en base de datos las
> palabras contenidas en el documento para hacer el buscador, pero
> esto ya muy para el final ;-)

Y los enlaces que hay de una página a otras dónde las guardamos?

>       -Se me olvidaba el detalle importante de ver que tipo de dato
> devuelve el servidor text/html, text/plain, .....

viendo la cabezera Content-Type que devuelve el servidor sería 
suficiente para determinar qué devuelve y si se procesa o no 
(suponiendo que esa cabecera sea fiable).

>
> 2.3- Esta parte de procesado es donde yo empezaria a dar resultados
> para hacerlos públicos. Es mucho mejor bajarte una pequeña BD con
> los enlaces que tener que bajarte todos los html's del site. Aqui
> ya las posibilidades son infinitas

bueno, yo me refería no a bajar o subir la BD completa, sino 
simplemente entradas sueltas de la BD (o bloques de entradas, para 
disminuir la carga de la red).
>
> 3- La apreciación de que se necesita un CVS me parece muy buena,
> ¿pero por qué no usar SourceForge? A parte de CVS tiene foros, para
> proponer mejoras, listas, ...

se me olvidó escribir que he visto que sindominio sí tiene un CVS.
Sourceforge es mucho más que CVS, es mejor. Como veáis
¿conocéis Savannah.gnu.org? creo que es parecido a sourceforge
Otra opción es que nosotros nosmontemos nuestro propio repositorio, 
pero eso implica tiempo y habíendo los que hay ya instalados...

>
> 4- Dada la gran modularidad del desarrollo yo no me preocuparia del
> lenguaje a usar o de la base de datos en demasia pero me voy a

hay que decidir muchas cosas antes de ponerse a codear, pero llegará 
un punto en que sí tengamos que definir estas dos cosas.

> mojar porque hoy estoy valiente. Para desarrollar dejaría una
> especie de torre de babel, pero sería muy exigente con dos cosas:
> definir el contrato de cada modulo y comentar bien el codigo para
> que cueste menos tocarlo por cualquiera. Para la base de datos

torre de babel?
contrato de los módulos? -> ep... espera, módulos= actividades?? ok, 
determinar qué se hace en debates, cursos, lecturas, material, prg... 
sí, desde luego.

desde luego hay que comentar bien (y esto no es comentar mucho, sino 
bien) y además ir escribiendo una documentación, no sólo para codear, 
sino tb. para escribir la documentación final sobre todo el proyecto.

> usaria unicamente SQL92 y encapsularia los accesos a esta a traves
> de clases, ya que si nos cansamos de MySQL podriamos usar
> PostgreSQL sin quebraderos de cabeza. Una BD de datos embebida
> pudiera ser incluso más rapida, pero teniendo unas clases que
> encapsulen el acceso a los datos en donde se almacenen es tontería.

no conozco SQL92, pero como veo que controlas de informática mira a 
ver si te haces un mensaje que explique qué son las clases, los 
árboles, las BD embebidas, las relacionales ya de paso y lo que veas 
que puede ser interesante. Tampoco hace falta que escribas mucho (si 
quieres sí desde luego)

>
> 5- Los datos de las bases de datos se podrían exportar en formato
> CSV para que cualquiera pudiera bajarselos y hacer con ellos lo que
> quisiera. Dibujines, organizar la "contra-resistencia", buscar el
> link más largo de todo sindominio, .... o lo que se quiera. Estos
> ficheros serian las fotos parciales de la topologia de los dominios
> a estudiar.

Esta info. debe quedar abierta a todos, aunque puede ser un tanto 
peligroso para las webs estudiadas que alguien conozca cómo han 
evolucionado, co se organizan, etc.
Esta cuestión es lo mismo que estar a favor o en contra del código 
abierto y el software libre. Qué pensáis?

>
> 6- Me voy a despedir ya que estoy poniendo muy canso.

nada, para eso está la lista, que lleva ya unos días quietecita.

Comentar que ya hay para un reto (detección de idioma) y para un 
debate (liberar la información generada), además del debate propio de 
cómo organizar la programación, que es básicamente lo que estamos 
haciendo en esta serie de tres mensajes.