Sandro Santilli - Sviluppatore Gnash

Lun, 21/11/2011 - 13:37
Ritratto di sagitter

Sandro Santilli - Sviluppatore Gnash

Inviato da sagitter 0 commenti

Avviciniamoci alle persone che stanno dietro allo sviluppo del software libero del quale tutti noi utilizzatori siamo tanto fieri, conoscendone uno di loro: Sandro Santilli (blog).

*
**
Sandro è uno dei developer che si occupa di Gnash (flashplayer free) ma non solo (vedi: strk.keybit.net/).

Da quanto tempo ti occupi dello sviluppo di Gnash ?

Ho cominciato a contribuire allo sviluppo di Gnash dal giorno stesso in cui il progetto venne annunciato. Cercavo da tempo un'alternativa libera al player proprietario che mi era necessario per eseguire applicazioni SWF che scrivevo senza aver strumenti validi per il debugging.

Perché, secondo te, i detentori della licenza del flashplayer (Adobe in questo caso) non rilasciano il proprio codice ? Non ne beneficerebbero in positivo dalle potenzialità del mondo opensource ?

Non posso rispondere io a questa domanda.
Ho il sospetto che la qualita' del codice non sia granche'. Magari se avessero aperto lo sviluppo ci sarebbero state piu' persone interessate ad averlo sugli iPad.

Ad oggi gnash-plugin, alla versione 0.8.9.5, ha raggiunto un ottimo livello d'integrazione con Firefox, Chromium e Konqueror; perché non spopola completamente tra gli utilizzatori delle distro GNU/Linux ?

Ultimamente molti contenuti SWF sul web sono pubblicati in una versione del formato non ancora supportata. Specialmente i siti di streaming video. Questa mancanza di supporto unita ad un maggior consumo di risorse puo' portare l'utente finale ad optare per l'installazione del player proprietario.

Tra l'altro molti siti web hanno un controllo javascript che in assenza di un plugin flash puntano direttamente sul sito della Adobe, per il download.

Dalla pagina dedicata a Gnash su *gnu.org si legge chiaramente che il plugin opensource supporta la versione 7 ed alcune versioni 8 e 9; mentre non supporta la versione 10. Perché esistono queste limitazioni ?

Dalla versione 9 del formato SWF e' stato introdutto un bytecode completamente differente dal precedente (rimasto pressoche' immutato dalla versione 5). E' tale bytecode (ABC) a non essere supportato dalla virtual machine di Gnash.

Dovevamo scegliere se investire di piu' nel supporto del nuovo bytecode o nella compatibilita' col vecchio. Gran parte del team ha considerato piu' produttivo migliorare la compatibilita' col vecchio, con risultati che credo siano ben visibili.

Come vedi la disponibilità del flashplayer proprietario per Linux che supporta anche le recenti versioni ? Ritieni che sia una sorta di concorrenza scorretta o denigrante ?

Non si puo' parlare di concorrenza perche' ci si rivolge a mercati differenti. Il flashplayer della Adobe puo' solo essere licenziato, mentre Gnash puo' essere esteso e customizzato per esigenze specifiche (esistono estensioni per interagire col filesystem o con un database direttamente da ActionScript, applicazioni per la conversione di filmati da formato SWF ad altri formati, etc.). Puo' essere ottimizzato per eseguire un'applicazione SWF su un dispositivo mobile.

Quanto è importante l'apporto degli utenti allo sviluppo di Gnash con la segnalazione dei bug ?

Avere riferimenti ad applicazioni SWF che danno filo da torcere a Gnash e' sicuramente d'aiuto, ma in questa fase la quantita' di bug noti supera di molto la capacita' del team di sviluppo di risolverli.

Gnash ha un set di testcase molto ampio. Il framework consente anche la codifica di bug noti e gia' in questa forma ci sono parecchi bug in attesa di risoluzione.

Un'aiuto molto importante allo sviluppo puo' venire da sviluppatori Flash, che possono implementare nuovi testcase (se non gia' presenti) per rendere evidente la causa principale di un supporto mancato. In cambio, tali sviluppatori avrebbero un player utile al debugging delle proprie applicazioni e sarebbero sicuri che il prodotto del loro lavoro sia compatibile con un popolare player libero.

Ovviamente perche' questa sinergia sia efficace gli sviluppatori Flash devono accettare di sviluppare utilizzando strumenti capaci di scrivere il formato SWF contenente il _vecchio_ bytecode (fino ad SWF8). La libreria Ming [1] e' una "grande vecchia" tra questi strumenti, e non a caso e' alla base di gran parte della testsuite di Gnash.

[1] http://strk.keybit.net/blog/2011/10/26/ming-0-4-4-released/

In futuro Gnash supporterà anche le nuove versioni di flash e magari eguaglierà il plugin proprietario ?

Finche' i proprietari del Flash riescono a convincere gli sviluppatori ad utilizzare l'ultima versione dei loro tool di creazione degli SWF non sara' facile raggiungere la piena compatibilita'.

Pubblicare SWF in formato 9 o superiore equivale un po' a fare siti che si possono vedere soltanto con IE (ricordate "best viewed with..." ?).

Sono gli sviluppatori Flash, e non la Adobe, a rendere la vita difficile a chi vuole utilizzare soltanto software libero. Come tutte le tecnologie proprietarie il Flash andrebbe evitato in tutto e per tutto.

Detto questo, e' stato raccolto un piccolo budget per indagare possibili approcci all'implementazione del nuovo bytecode, ma ancora nessuno si e' fatto avanti con una proposta concreta.

Quando pensi che sarà disponibile la prossima versione di Gnash ? Quali saranno le maggiori novità ?

Teoricamente siamo gia' in feature freeze.
Le novita' dal NEWS file:

* Qt4 GUI supports mouse wheel, clipboard, and screen resolution.
* Enhanced UI support for script limits (abort popups, user prefs).
* BitmapData functions copyPixels(), copyChannel(), perlinNoise()
and noise() implemented.
* Node id mapping in ActionScript XML class implemented (XML.idMap).
* Fix dispatching of Sound.onLoad event, fixing google dict audio.
* Fix support for control tags found after last expected frame (#33176).
* Fix support for uncompressed sound with gstreamer media handler.
* Implement Button.getDepth(), fix button key events.
* Fixes to startDrag and stopDrag opcodes.
* Implement onSoundComplete() for event sounds (#23020).
* Fix MovieClip.onLoad event dispatching and constant pools handling, fixing
support for movies generated by the evil Adobe Captivate tool (#33521).
* Fix unattached Sound.stop() semantic (#33888) enjoy Super Mario!
* OpenVG renderer added.
* Improved framebuffer GUI and touchscreen support.
* Framebuffer now supports using multiple renderers.
* Refactored input device support.
* Fix parsing of lossless 16bit bitmaps, fixing support for movies
generated by the evil TechSmit Camtasia tool (#34625).

Ci sono alcuni bug [1] che bisognera' aggiustare prima di poter rilasciare la prossima versione. Qualunque contributo alla risoluzione dei bug (monetario o tecnico) avvicinera' la data di rilascio.

[1] Link

Il tuo impegno per il software libero è ammirevole, pensi che le attuali distribuzioni siano sulla strada giusta ?

Indubbiamente le attuali distribuzioni hanno raggiunto un livello di usabilita' che ai tempi dei miei inizi erano impensabili. In questo modo aumenta la base degli utenti, ma non necessariamente quella degli sviluppatori. La cultura della partecipazione potrebbe trovare maggiori stimoli.

Sono anni che non seguo piu' le varie distribuzioni. A me basta un terminale ed un server X, da dove arriva arriva.
Mi piace la comodita' del package manager ed ho imparato ad usare quei 2/3 comandi che mi permettono di trovare quel che cerco. Ho imparato ``apt'' quindi evito le distribuzioni che usano altro (sorry).

Mi sembra una strada giusta quella di standardizzare il sistema di packaging, quindi
appunto la possibilita' di pubblicare repository di pacchetti. Gnash ne ha uno proprio su cui vengono pubblicati degli snapshot periodicamente (vedere wiki per dettagli).

Grazie Sandro

*L’articolo può essere copiato e condiviso liberamente citandone la fonte
**Articolo tratto dal blog fedora-os.org