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

Pirla the.pirla@flashnet.it
Mar 12 Giu 2007 21:40:51 CEST


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à.
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.
 
> <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.

> 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
        Pirla

Per rispondere in E-mail the (punto) pirla (chiocciola) flashnet.it
*** un bacio ai pupi ***

---> Linux user since yesterday <---
--->     Linux User #389536     <---


Maggiori informazioni sulla lista gl-como