Friday, April 07, 2006
sul sondare
Uno di quegli altri problemi di cui si accennava poco addietro riguarda la riorganizzazione di tccat. Come spesso accade di recente, mentre cercavo di capire com'era la situazione attuale al fine di migliorarla, mi sono imbattuto in un altro problema interessante: il probing dei file.
sia tccat sia tcprobe necessitano, per motivi diversi, di analizzare il contenuto del file che devono trattare. tcprobe, per ovvie ragioni; tccat perche` deve trattare tipi di sorgenti diversi in modo diverso, proprio per fornire un'output uniforme a chi a sta a valle. Un esempio chiarificatore in tal senso e`
tccat -i /dev/dvd
tcatt -i /una/directory/con/tanti/file/avi
Vale dunque la pena farsi un'idea su come funziona adesso il probing qua in tc-landia, cosa piace, cosa non piace, cosa va, cosa non va etc. etc. Per ora non ho ancora dato un'occhiata intorno per vedere se c'e` qualche best practice o anche solo come fanno i migliori della classe (...), ma conto di farlo prima di metter mano al codice.
A grandissime linee, ora come ora, la cosa funziona cosi`:
1) decido il macro-tipo della sorgente a partire dal suo PATH e dai metadati che mi offre l'OS
2) specifico il tipo della sorgente con opportune azioni dipendenti dal macrotipo
3) utilizzo codice specifico del tipo di sorgente per determinarne le caratteristiche
Ora, limitatamente a tccat ci si ferma subito a 1), mentre tcprobe necessita (e usa) anche 2) e 3). Riorganizzare 1) e` gia` di immediato interesse perche` pare che -al momento in cui scrivo- FreeBSD -current abbia gia` saltato il fosso abbandonando la faccenda major/minor su cui si basava (gran) parte dell'euristica precedente. Devo informarmi meglio su questa faccenda, ma pare ormai una questione di quando piuttosto che di se.
Prima di farmi una cultura in merito, non ho ancora idee su come migliorare (ci si prova, almeno) lo stato di cose, se non talmente ovvie e generiche che neppure vale la pena riportarle.
Anche il punto 3) lo liquido in due parole perche`, per come la vedo io (e potrei vederla storta, non lo escludo) quando uno arriva al punto 3) dovrebbe avere gia` le idee sufficientemente chiare per partire in tromba con una cosa tipo (uno tra i succitati, ovviamente)
AVI *avi = avi_open(filename, ...);
MPEG_TS *mpgts = mpeg_ts_open(filename, ...);
WAV *wav = wav_open(filename, ...);
OGG *ogg = ogg_open(filename, ...);
e morta li, prendendo le informazioni sulla sorgente, se servono, dal descrittore cosi` ottenuto, senza tanti complimenti.
Ora veniamo alle dolenti note, il punto 2). Attualmente il concetto di fondo prevede di leggere una piccola quantita` di byte (fino a 16) all'inizio della sorgente, e cercarvi dei pattern noti.
Da li dedurre il tipo di file. Un po` come fa libmagic e il comando file, per intendersi. (vedasi libmagic (3), magic (5) e file (1)). Il concetto me gusta, mi pare -per quel che ho visto sinora-
decisamente non banale fare meglio, al netto di una gestione sana di quanto letto in eccesso (aka: evitiamo i problemi leggendo da pipe). L'implementazione non me gusta, trattandosi in per di un grosso if () { goto } if () { goto } ... (gia`, goto).
Oltre al fatto che la si puo` sfangare tranquillamente in modo piu` elegante con una classica catena if () { } else if () { } , non mi piace affatto l'idea di avere i pattern incorporati nel codice. Sarebbe decisamente meglio separare dati -questi dati- dal codice.
Al che, in pratica, si arriverebbe ad una reimplementazione di libmagic, personalizzata per le esigenze di tc. Varrebbe la pena?
Beh, francamente mi piacerebbe evitarlo. Il valore da salvare, qui, e` senza dubbio il database di associazioni pattern-tipo di file. Sarebbe anche piu` razionale incapsulare questo database... In un database appunto, tipo quello di magic. Riscrivere del codice per gestire detto database, poi, se possibile vorrei evitarlo in quanto ha tutta l'aria, ora come ora, di lavoro inutile & duplicato.
L'idea, quindi, e` quella di verificare la fattibilita` di scriversi un database custom (perche` potremmo aver bisogno, e anzi quasi sicuramente avremo, di un livello di dettaglio maggiore di quanto comunemente richiesto) per magic e di sfruttare libmagic (66k lo shared object qui su amd64) per i nostri fini.
Scriversi materialmente il DB dovrebbe essere solo questione di tempo & noia, quindi il punto principale e` capire se libmagic esiste su tutte le piattaforme che ci interessano (Linux/*, Free/Net/OpenBSD e Darwin, praticamente), e sopratutto se tutta questa manovra incontra il consenso degli altri sviluppatori di tc.
Ah, della riorganizzazione di tccat con cui ho aperto il post se ne parlera` piu` avanti, quando si potra` metter mano a ViM per iniziare i lavori in merito.
// posted by Ikitt @ Friday, April 07, 2006 
Subscribe to Posts [Atom]