[gl-como] Summer of code - breve descrizione del progetto

Mar 12 Giu 2007 22:40:49 CEST

Pirla ha scritto:
> Il giorno mar, 12/06/2007 alle 13.40 +0200, Riccardo (SCASI) ha scritto:
>
>   
>>> Per quanto riguarda il filesystem, non è necessario inventare nulla.
>>> I vari FS che già sono implementati si prestano bene a queste cose.
>>> Penso ad ext2, ext3, reiserfs per non parlare del progetto FUSE.
>>>       
>> io i filesystem li lascerei stare del tutto, fare qualcosa di 
>> stabile/usabile etc. etc. richiederebbe non 3/spare time ma 30/full time 
>> mesi (IMHO).
>>     
> Non capisco... spiegati meglio.
> O meglio provo a spiegarmi io.
> Quello che mi piacerebbe ottenere è proprio una struttura che
> appoggiandosi ad una base dati, generi una struttura simile ad un file
> system.
> In questo modo tutti i software già esistenti che permettono di accedere
> ad un filesystem sono in grado di sfogliare questa struttura di dati,
> presentarla in diversi modi (grafici o meno) e di accedere al dato
> cercato.
>
>   
>>> il progetto FUSE, in una prima fase lo scarterei per due motivi:
>>> 1. non è stabile (e ci sono un sacco di doc al riguardo anche per
>>> gnome-vfs per esempio)
>>> 2. non esiste su tutti i sistemi operativi.
>>>       
>> ?!?! non capisco questo punto, nemmeno ext{2|3}, reiser.. esistono per 
>> tutti i sistemi operativi
>>     
> Linux permette di montare diversi filesystem, e nessuno è proprietario.
> Inoltre permete di montare filesystem "proprietari".
> La struttura modulare del kernel permete di virtualizzare praticamente
> qualunque filesystem ed astrarre dal modo con cui esso viene scritto su
> disco.
> Ci sono filesystem che neanche risiedono sul server, ma vengono acceduti
> via rete (primo fra tutti NFS).
> Per questo motivo, appoggiarsi al filesystem (generico senza andare su
> un FS specifico) è un vantaggio rispetto all'uso di FUSE, proprio per la
> portabilità.
>   
io intendevo usare fuse, perché più che un file system, lo considero una 
rimappatura di dati generici in un formato cartelle/file, previa 
scrittura di un programma (Non modulo) apposito.
va da se che non può girare su sistemi non Linux !
(A meno che il progetto non giri su un server linux e si esporta la 
cartella con samba per esempio)


> Non sono neanche sicuro che FUSE sia usabile sui server di produzione
> che usano versioni Enterprise di Linux (penso a SUSE e RedHat per
> esempio). Qualcuno ha notizie al riguardo?
> In poche parole il massimo sarebbe gestire il dato senza preoccuparsi di
> dove esso sia.
>
>   
>> io gli xattr li utilizzerei solo per 'marcare' un file come gia' 
>> catalogato, eventualmente indicando la 'versione' del software di 
>> catalogazione in modo che si possa sapere se va ricatalogato (es la 
>> nuova versione estrae info aggiuntiuve).
>>     
> Questo sarebbe controproducente, e soprattutto sarebbe una informazione
> ridondata.
> Questa informazione sarebbe già nel DB. E se perdo il DB questa
> informazione sarebbe inutile.
>   
comunque, se perdo il DB, al massimo rifaccio una scansione per 
ripopolare un nuovo DB, o rischio di perdere attributi non più 
ricostruibili ?

>  
>   
>> <flamewar on>
>> per favore non utilizzate mysql (postgresql rules) :-)
>> <flamewar off>
>>     
> Stessa cosa che per i file system.
> E' vero che ci sono funzionalità particolari di un DB Server che
> potrebbero non trovarsi in un altro DB Server, ma se si riuscisse ad
> astrarre dal Server, allora la flessibilità sarebbe ancora maggiore.
> Ognuno può scegliere quale DB Server installare (se non ce l'ha già)
> oppure usare quello che si trova installato , senza doverne installare
> un altro.
>
>   
>> mi sembra la soluzione piu' abbordabile, con i dati non aggiornati in 
>> tempo reale ma attraverso un processo schedulato.
>> Per quanto riguarda la popolazione iniziale DB (e avere dati per capire 
>> come strutturarlo al meglio) si potrebbe scrivere un programmino (anche 
>> uno script bash), chiamiamolo 'gl-como-catalogatore' al quale dare in 
>> pasto tutti i file 'papabili'.
>>
>> find /directory/da/catalogare -exec gl-como-catalogatore "{}" \;
>>     
> Quì entriamo già nel modo di fare le cose, e penso che prima di
> addentrarci in questi aspetti bisognerebbe capire cosa c'è da fare.
> io ho un'altra idea, abbastanza diversa, ma per il momento non dico
> nulla proprio perché voglio farmi un'idea più precisa e soprattutto
> valutare diverse soluzioni ed evidenziarne, più che i pro, i contro.
>   
direi che domani sera, Ambrogio (Visto che l'idea del progetto è sua) 
dovrebbe esporre per primo quello che ha in mente, anche se non dovesse 
avere un idea precisa già pronta, poi, e solo poi, possiamo scannarci 
tipo assemblea condominiale per tutto quello che riguarda il progetto, 
il/i linguaggi da usare, DB etc.... :-)

>   
>> io anni fa avevo fatto una cosa simile per popolare un db con i dati di 
>> tutti i miei file mp3 (e li mi ero fermato)
>>     
> Buon punto di partenza... si potrebbe riutilizzare il codice?
> E' opensource? ;-)
>
> Visto che non puoi venire, ci terremo in contatto via mail.
> A presto
>
>   
ciao

-- 
Brisa Francesco
Via Gabelli 16
22077 Olgiate Comasco (CO)

http://brisa.homelinux.net
francesco@brisa.homelinux.net

      ________                ______
     / ____/ /               / ____/___  ____ ___  ____
    / / __/ /      ______   / /   / __ \/ __ `__ \/ __ \
   / /_/ / /___   /_____/  / /___/ /_/ / / / / / / /_/ /
   \____/_____/            \____/\____/_/ /_/ /_/\____/

http://www.gl-como.org

My public gpg key:
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0xC67DC12DC4361693