Thursday, November 10, 2005
tempo di cambiamenti
La roadmap per la 1.1.0 di transcode non e` ancora stata tracciata con chiarezza, e questo sinceramente mi indispone alquanto. Dal canto mio, l'idea e` di incorporare i cambiamenti di cui vado a parlare, piu` gli ovvi bug-fix e correzioni semplici (2-3 righe), e poi di rilasciare. Si, credo ancora in "release early, release often" ;)
Dopo un breve scambio di email su transcode-devel, si e` giunti alla conclusione che la cosa migliore e` cominciare a lavorare per la separazione codec/(de)muxer; purtroppo, mpeglib dovra` attendere ancora. Il mio piano e` dunque quello di iniziare a lavorare (in time sharing stretto con gli impegni universitari) sul nuovo export layer modulare.
Perche`?
Perche` e` il layer piu` facile, e perche` ho gia` fatto esperimenti in merito che dovrei poter riciclare in buona parte. Tutto sara` comunque ampiamente discusso su transcode-devel, e conto di procedere per gradi. Dubito che il nuovo loader di moduli possa rientrare in questo quadro, ma neanche lo escludo a priori.
Riguardo mpeglib, la nuova previsione realistica (ma con un pizzico di ottimismo) e` quella di iniziare i lavori ufficiali durante le vacanze di Natale 2005.
E` dunque possibile (e anzi, io spingero` in questa direzione) che la 1.1.0 esca asimmetrica, col nuovo layer modulare in posizione ma con gli altri due (import e filter) vecchio stile.
Questo e` brutto in apparenza, in pratica un'analisi men che superficiale mostra che gia` adesso i layer non sono allineati: i programmi di supporto sono presenti solo in import, solo export ha un meccanismo tipo aud_aux, filter ha un'API diversa dagli altri due...
La roadmap per il nuovo export layer e`, in linea di massima:
1) merge della patch -con piccole modifiche- per il 'modular encoder'
2) potenziamento del sistema di capability con nuove funzioni di supporto, e forse anche nuove strutture dati, in libtc
3) adattamento del loader di moduli attuale; forse introduzione del nuovo, ma non e` cosi` probabile. Sicuramente proporro` l'idea di introdurlo nel prossimo futuro
4) adattamento dell'encoder
5) riscrittura di tutti i moduli di export (!!!)
And That's all folks ;)
Dopo un breve scambio di email su transcode-devel, si e` giunti alla conclusione che la cosa migliore e` cominciare a lavorare per la separazione codec/(de)muxer; purtroppo, mpeglib dovra` attendere ancora. Il mio piano e` dunque quello di iniziare a lavorare (in time sharing stretto con gli impegni universitari) sul nuovo export layer modulare.
Perche`?
Perche` e` il layer piu` facile, e perche` ho gia` fatto esperimenti in merito che dovrei poter riciclare in buona parte. Tutto sara` comunque ampiamente discusso su transcode-devel, e conto di procedere per gradi. Dubito che il nuovo loader di moduli possa rientrare in questo quadro, ma neanche lo escludo a priori.
Riguardo mpeglib, la nuova previsione realistica (ma con un pizzico di ottimismo) e` quella di iniziare i lavori ufficiali durante le vacanze di Natale 2005.
E` dunque possibile (e anzi, io spingero` in questa direzione) che la 1.1.0 esca asimmetrica, col nuovo layer modulare in posizione ma con gli altri due (import e filter) vecchio stile.
Questo e` brutto in apparenza, in pratica un'analisi men che superficiale mostra che gia` adesso i layer non sono allineati: i programmi di supporto sono presenti solo in import, solo export ha un meccanismo tipo aud_aux, filter ha un'API diversa dagli altri due...
La roadmap per il nuovo export layer e`, in linea di massima:
1) merge della patch -con piccole modifiche- per il 'modular encoder'
2) potenziamento del sistema di capability con nuove funzioni di supporto, e forse anche nuove strutture dati, in libtc
3) adattamento del loader di moduli attuale; forse introduzione del nuovo, ma non e` cosi` probabile. Sicuramente proporro` l'idea di introdurlo nel prossimo futuro
4) adattamento dell'encoder
5) riscrittura di tutti i moduli di export (!!!)
And That's all folks ;)
// posted by Ikitt @ Thursday, November 10, 2005 
Subscribe to Posts [Atom]