Re: Indicizzare il contenuto dei files nell'hd
On Wednesday 14 July 2004 13:25, Gandu wrote:
> Ho cercato in tutti i modi di trovate un modo univoco per gestire le
> mie informazioni, quello che c'e' sul mio HD. Ho provato a elaborare
> sistemi per convertire tutto in XML, usare per tutto un database,
> costruire sistemi piu' o meno elaborati per prendere note, stendere
> documenti, archiviare informazioni. E' una strada __non__
> percorribile senza elaborare delle linee guida e soprattutto
> impossibile da integrare con i documenti provenienti dall'esterno,
> che sono 80% del totale. Almeno se uno deve anche vivere nel
> frattempo...
>
> Pero' mi sono accorto che su Google.com trovo tutto e uso un solo
> campo per la ricerca.
>
> Far indicizzare a Google il mio HD e' impossibile (o quasi :-)), ma
> avere un sistema come Google sul proprio HD non e' impossibile.
>
> La mia nuova idea e' quella di costruire uno script (Perl, bash, php,
> ???) che ricorsivamente indicizzi tutta la mia HOME, aprendo un certo
> set di file (testo, pdf, html, rtf, MSdoc, openoffice, magari
> immagini) e ne salvi il contenuto in un database MySQL, assieme al
> PATH assoluto e le informazioni del file stesso (formato, peso, data,
> permessi).
>
> L'interrogazione del DATABASE dovrebbe avvenire attraverso una
> semplice SQL, ma questa e' la parte facile.
>
> C'e' qualcuno che mi aiuta?
E' un mio vecchio pallino, e in questo periodo un po' di tempo libero ce
l'ho. La mia idea sarebbe quella di fare un modulo per fuse (filesystem
in userspace) che tiene tutti i file di un utente. I file vengono
salvati normalmente in una directory, ma vengono automaticamente
indicizzati, tipati, scannati e chi più ne ha più ne metta.
L'implementazione non è, in teoria, molto lunga, e può essere fatta in
maniera estremamente modulare: da un lato il modulo per fuse,
dall'altro un buon insieme di programmi di indicizzazione e accesso ai
file. La speranza sarebbe di poter usare tanti linguaggi diversi
(possibilmente con una architettura a plugin che consenta di scrivere
con facilità binding per mono e corba) per scrivere "indicizzatori" che
si preoccupano di accettare un file in input e restituire qualcosa tipo
uno script SQL in output. Un approccio di tipo filesystem potrebbe
consentire (con relativa facilità, perchè fuse è molto semplice) di
creare directory che in realtà sono query o view sul database, in modo
da poter sfruttare la potenza del nuovo approccio anche con i vecchi
programmi.
Se qualcuno condivide queste idee, io sono in fase positiva
in questo periodo :) Naturalmente l'approccio sarebbe e/o sarà
incrementale, tentare di realizzare una piccola base molto solida da
estendere. Ho sentito molto spesso parlare di progetti simili, ma mai
nessuno ha superato la fase "planned", e in questo bisognerebbe
impegnarsi: scegliere il più possibile "standard de facto" per la base
del sistema, e implementarla. Cmq è più di un anno che non cerco roba
del genere, magari qualcuno è più avanti di me che sono in
pre-planned...
Altre possibilità interessanti che si potrebbero inserire a posteriori
se vengono tenute presente durante la prima implementazione, sono
plugin che rappresentano directory, per esempio per l'accesso ai file
zippati o alle mailbox, e plugin di classificazione bayesiana che
sarebbero molto utili, nella "generazione della roba" come la chiami
tu, per individuare il materiale "simile a" quello su cui stiamo
lavorando, oppure la checksum md5 di ogni file inserito nel sistema, in
modo da identificare velocemente i duplicati, oppure ancora plugin che
consentono di vedere un file in un modo diverso, con possibilità di
caricare e salvare in un formato e tenere il file "reale" in un altro
formato, per esempio per dare una interfaccia xml a molti file di
configurazione unix in modo da avere uno strumento di configurazione
unico, o anche il versionamento di alcuni file critici. Ma questa parte,
lo riconosco, è decisamente troppo ambiziosa per il momento!
V.
--
Non so chi colpire perciò non posso agire
[Afterhours]
Reply to: