El día 28 de julio de 2008 0:11, Rodrigo Fuentealba <[EMAIL PROTECTED]> escribió: > El día 28 de julio de 2008 5:43, Aldrin Martoq <[EMAIL PROTECTED]> escribió: >> >> Bueno, asincronismo javascript dhtml y todas esas cosas que el buzzword >> resume en AJAX. Estoy seguro que se puede hacer algo como lo que pido, >> multiplataforma (asincronismo javascript dhtml etc) y localmente. La >> parte XML la quiero obviar! ;) > > Ok. > >> Aqui una prueba, que estoy estudiando como usar: >> http://www.ecosmear.com/relay/ >> >> Parece que lo top en esto es Prototype y Script.aculo.us. > > Asi es. > >>> 2.- Tener un índice de los archivos implicaría (ambas): >>> 2.a.- Que tengas algo así como PostgreSQL embebido usando TSearch2 >>> 2.b.- Que tu backup sea de 2Gb + 2Gb de datos de la PostgreSQL + el resto. >> >>> 3.- En el mejor de los casos, a medida que vas agregando archivos al >>> respaldo, puedes ir generando un índice y antes de "Burn" agregar >>> también este archivo; >>> algo ilógico y difícil. >> >> Es un indice de "palabras", no tienes que hacer scan del contenido. > > Entiendo ese indice como lo que hace TSearch2 para optimizar el tiempo > de las búsquedas de textos. Quizás puedes usar un modelo simplísimo > como (lo escribiré en SQL, pero lógicamente es trivial de hacer hasta > con CSV): > > CREATE TABLE archivo > ( > id integer, > archivo longvarchar > ); > > CREATE TABLE palabra > ( > id integer, > palabra varchar > ); > > CREATE TABLE palabraarchivo > ( > palabra_id integer, > archivo_id integer, > foreign key (palabra_id) references palabra (id), > foreign key (archivo_id) references archivo (id) > ); > >> Basicamente una lista de palabras y cada palabra tiene una lista de >> archivos que contienen dicha palabra. > > Mejor una lista de archivos, una de palabras y una relación entre > ambas... no hay redundancia de esta manera ;-). > >> Luego ante una busqueda haces un >> scan sobre la lista de palabras y tienes todos los archivos. Es muy >> eficiente, ya tengo una aplicacion pygtk que lo esta haciendo bastante >> bien y rapido sobre 70.000 archivos, por ahora solo con los nombres de >> archivo > > ¿Cómo lo haces para identificar los archivos que debe escanear y los > que no? Por ejemplo, los binarios deben contener strings dentro de > ellos, pero no me interesa leer esos archivos. > >> falta programar que agregue mas palabras al indice escanenado >> el contenido de los documentos, pero ya con lo que tengo es bastante. >> >> No necesitas base de datos ni nada muy complejo, la busqueda no es tan >> extensa y de todas formas hay que hacer un scan de todas las palabras >> (recorrer todas las filas). A menos que busques de otra forma (similitud >> de palabras por ejemplo?) > > SOUNDEX, LIKE; estaba pensando en eso. > >> Tampoco tienes el problema de las actualizaciones del indice, pues lo >> regeneras de nuevo; el indice no se actualizara en un DVD o respaldo. > > Un archivo de base de datos SQLite, o en el peor de los casos, tres > archivos DBase. Si incluyes un binario estático de una aplicación que > los lea, podrías usarlo en varios Linux (y en MacOS, quizás?). Y es > trivial hacer algo para Windows (ya que es la única plataforma que no > asegura que tus programas corran ahí) con eso. > >>> Siempre puedes cocinar algo con find, grep, sed, awk, xargs, locate; >>> en una de esas te conviene hacerte utilidades que busquen en el disco >>> entero y agregar esas utilidades a cada uno de los backups. >> >> Ya he hecho eso, y a mi no me funciona... De hecho, no encuentro el >> ultimo catalogo que hice de esta forma (a punta de find's y rotulado de >> discos a manopla) > > :s > > Por eso prefiero usar nombres descriptivos en mis archivos. > > -- > Rodrigo Fuentealba > Concepción, Chile > >
Fuera del dilema técnico que está en discusión actualmente, y que encuentra bastante interesante, me han surgido alguna preguntas que... bueno, cualquier end user se hace. - ¿Qué clase de catálogo quieres buscas hacer? ¿De cada Disco o de una serie de respaldos (respaldo-pt1, respaldo-pt2, etc)? - ¿El ejecutable viene en el disco? - ¿Existirá esto para end users en algún futuro próximo? Y aparte de eso, estaba pensando en qué tan dificultoso sería que trabajaras eso con una base SQLite, tal como hace Firefox actualmente (aunque consumiendo menos RAM). A lo mejor por ahí va la cosa... Saludos, y éxito con tu trabajo. :D
