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

Lun 11 Giu 2007 21:25:07 CEST

Pietro "m0nt0" Montorfano ha scritto:
> Pirla ha scritto:
>   
>> Il giorno dom, 10/06/2007 alle 23.36 +0200, francesco ha scritto:
>>
>>     
>>> da quello che mi immagino, finita la fase di catalogazione dei files (In 
>>> un DB penso), l'esportazione potrebbe essere fatta tramite "fuse"
>>> montando una cartella fittizia nella home dell'utente per esempio;
>>>       
>> Questa potrebbe essere una strada, ma ce ne sarebbero anche altre.
>> Bisogna pensare, tirare fuori le idee, fare brain storming e poi (ed in
>> questo io sono molto bravo) trovare i punti deboli della situazione.
>>
>>    
>>     
>>> intendi questi come tag:
>>> http://en.wikipedia.org/wiki/Extended_file_attributes
>>>
>>> oppure quelli tipo contenuti nei file ogg/mp3 ?
>>>       
>> Tutti quelli possibili, senza limiti
>>
>>     
>>> visto così il progetto sembra già più interessante e di interesse 
>>> pratico (Anche per chi ha il suo semplice desktop).
>>>
>>> sarebbe bello capire cosa si potrebbe fare nel cosa qualcuno aggiungesse 
>>> un file / directory nel file system esportato, ad esempio, se prendo un 
>>> file ogg e lo copio nella cartella:
>>>
>>> |-- audio
>>> |   `-- ogg_vorbis
>>>
>>>
>>> oppure lasciare le cartelle in sola lettura (Ma non i singoli file).
>>>       
>> Dipende... in una prima fase potrebbe essere solo di consultazione e
>> catalogazione, e quindi magari all'inizio sarebbe senza filesystem, ma
>> solo con un'interfaccina web o simili.
>> Poi estendendo il tutto con FUSE si può semplicemente fare in modo che
>> scrivere un file in una qualsiasi cartella del FS serve solo a dire:
>> cataloga questo file che non è stato ancora catalogato, oppure dimmi se
>> è già stato catalogato.
>> Ci si deve pensare... e bisoga vedere bene le caratteristiche di FUSE.
>> io non sono riuscito ancora a capire bene come funziona. Ho solo colto
>> le potenzialità della cosa.
>>
>>     
>
> Bello e interessante, devo inoltre dire che mi ricorda il progetto di 
> una nota softwarehouse che diceva che il suo ultimo prodotto doveva 
> avere il filesystem in sql, cosa che a me attirava veramente ma 
> veramente tantissimo, putroppo questa "feature" è saltata e delle cose 
> interessanti per quel sistema operativo non ne sono rimaste....
>
> Volevo fare qualche piccola osservazione dal punto di vista pratico:
> - Si parla di realizzare un filesystem, questo implica la progettazione 
> di un filesystem appunto che vuol dire gestione partizioni e gestione 
> disco a livello infimo (mooooolto basso), ora mi piacerebbe, solo che lo 
> vedo come un lavoraccio e pure cattivo perchè andrebbe implementato 
> anche un minimo di journaling (se si scrive cosi). Se siamo consapevoli 
> di cio, ammesso che non stia sbagliando, io sono a favore del 
> filesystem, solo che è un lavoro grosso.
>   
Utilizzando fuse, non si andrebbe a scrivere un filesytem gestito tipo 
il modulo del kernel di ext3 o ex2, ma sarebbe un programma che gira 
esternamente al kernel e che risponde mette a disposizione delle 
funzioni che vengono chiamate dal kernel, le funzioni restituiscono dati 
come ad esempio una lista di files/directory, il contenuto di un file, 
modifica, aggiunta, rimozione etc..., ma tutto a livello virtuale, 
vedila di più come se fosse una interfaccia ad un file zip che viene 
montato su una cartella (Per altro esistono vari prg fuse che lo fanno).

per tagliare la testa al toro e mostrarne la semplicità di fuse vedi hello.c

compilato con:
gcc -Wall `pkg-config fuse --cflags --libs` hello.c -o hello

inoltre, si può fare il programma per fuse anche in java, c#, python, 
perl volendo, esistono appositi wrapper.

> - Superata la cosa del filesystem, il numero di file prsenti in un 
> desktop medio, senza particolari periferiche e con harddisk standard 
> attuali che sono circa da 200Gb sono tanti (penso al mio, che comunque 
> ha i suoi 51Gb di partizione di cui solo 18 in uso, dando "locate * | wc 
> -l", ho 278860 file, che schifo), le informazioni in un db sarebbero un 
> sacco e su un server magari anche solo con un hdd esterno attaccato 
> sarebbero molte molte molte di piu. Questo significa che il db deve 
> essere progettato non bene, di piu, e soprattutto che va usato un db 
> server decente e veloce (mysql diventa un chiodo con query tipo "select 
> count(*) from..." se la tabella ha molti record, parlo già dai 500000 
> credo) e oltre tutto il db è salvato anch'esso su hdd, se è gigante 
> occuperà un frego di spazio.
>   

be, non salviamo tutti i file, solo alcuni (multimediali/documenti), 
quindi il numero scende molto, direi max 10000 per un uso medio
poi, ogni record sarebbe penso al massimo di 2 - 3 KB, quindi max 30 MB 
di DB (Forse sono troppo ottimista ?)

comunque mysql, può fare ricerche in milioni di record molto 
velocemente, con le giuste query ed i giusti indici sulle tabelle (Per 
fortuna)

> - La modularità dell'applicazione puo esserci se effettivamente si 
> rimane ad un'applicazione, se si fa un filesystem autoadattante mi sa 
> che se ne va a farsi benedire
>
> Comunque, progetti da cui prendere spunto ce ne sono: beagle per 
> l'indicizzazione, tripwire o qualcosa di simile per monitorare lo stato 
> dei file, file (si il programmino da linea di comando) per identificare 
> il tipo di file in questione...
>
> Detto cio l'idea mi piace un sacco assai, nonostante le osservazioni che 
> pero vogliono essere costruttive eh e non vedo l'ora di iniziare a fare 
> qualcosa :D
>
> Si potrebbe fare oltre l'interfacciamento web anche quello via cellulare 
> (lo so che è una cosa inutile, ma a qualcuno potrebbe interessare), e 
> non è troppo complicata.
>   

sì vedrà :-)
ciao
> Ciao!!
>
> Pietro
>
> P.S. mamma mia, come mi son preso bene a leggere il progetto sta mattina!!!
>
>   

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

-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        hello.c
Tipo:        text/x-csrc
Dimensione:  2191 bytes
Descrizione: non disponibile
Url:         http://lists.linux.it/pipermail/gl-como/attachments/20070611/6576c3f1/attachment.c 