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

[Riccardo (SCASI)]

Pirla ha scritto:
> Il giorno lun, 11/06/2007 alle 08.57 +0200, Pietro "m0nt0" Montorfano ha
> scritto:
> 
>> P.S. mamma mia, come mi son preso bene a leggere il progetto sta mattina!!!
> Lasciamo perdere i commenti alle tue note a qualche mail futura, magari
> anche dopo che ci siamo visti di persona.
> Sono molto contento che il progetto abbia "preso" un bel po' di gente.

sicuramente non potro' essere presente alle varie riunioni quindi potro' 
'partecipare' solo in lista. Ecco i miei 0.02 euro dal basso della mie 
conoscenze.

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

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

> 
> l'utilizzo degli xattr è da prendere in considerazione, ma con le dovute
> cautele.
> Chi di voi ha un FS montato con gli xattr attivati? (IO NO)

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

> 
> Comincerei dalla parte che serve a catalogare i file. In questo modo
> riusciamo a decidere la struttura del DB e ad avere un'idea di quanto
> potrebbe essere grosso.

<flamewar on>
per favore non utilizzate mysql (postgresql rules) :-)
<flamewar off>

> La generazione dell'albero del "nostro filesystem" (andrà inventato
> anche un nome) potrebbe cominciare con la semplice creazione di link
> simbolici verso i file veri.

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 "{}" \;

inizialmente gl-como-catalogatore potrebbe essere uno script che esegue 
una serie di programmi (i plugin) che estraggono le informazioni dal 
file e popolano/aggiornano il db. Tipo

<script>
...faccio alcune cose...
for p in /etc/gl-como-catalogatore/plugins
do
	/etc/gl-como-catalogatore/$p "$1"
done
...faccio altre cose...
</script>

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)

> 
> Ci sono una serie di problemi da affrontare, ma secondo me tante teste
> riescono a tirare fuori un bel po' di idee.
> Ho visto che in molti hanno già fatto ricerche sul web per cercare di
> carpire dagli altri qualche idea, e questo è molto positivo. Ci sono
> tanti progetti e se riusciamo ad entrare nella filosofia UNIX (fai una
> cosa sola ma falla bene) e tutti i moduli possono funzionare in modo
> parallelo ed indipendente, allora secondo me siamo a cavallo.
> In molti ci hanno pensato, ma nessuno ha mai fin'ora messo le mani sulla
> tastiera per tirare fuori qualcosa di usabile (a parte le grandi
> software house che si fanno pagare un sacco).
> 
> Chi ci sarà domani sera?
> 

come gia' detto, purtroppo no

ciao
riki