Fratelli coltelli

Premessa: OK, ci sono cascato. Il pesce d'aprile consisteva nel fatto che non si trattava di un pesce d'aprile...

Lo so, pensavate che Marvel Civil War vi avesse messo davanti la scelta più difficile della vostra vita. Capitan America o Iron Man¹? Mister Fantastic o la Donna Invisibile²? L'Uomo Ragno con il tradizionale costume rosso e blu o con quello ipertecnologico rosso e oro³?

No, purtroppo l'era delle scelte non è affatto finita. Ora ve ne attende un'altra: per GNOME/GTK+ è meglio Gecko o WebKit [o entrambi]?

Ma peeeercheeeeé?

"Che ce ne cale?", direte voi "Facciamo un bel livello d'astrazione (magari anche switchabile a runtine) e chi se importa di quello che c'è sotto".

PEEEEEEEB - risposta sbagliata.

Parole di Alp Tocker, non mie, scritte qualche tempo fa (a commento del bug per Yelp per tenere traccia del porting su WebKit), ma pare che a seguire tale strada si avranno solo due grossi problemi:

1. gli attuali livelli di astrazione disponibili (in yelp, devhelp, epiphany e altrove) tra applicazione ed engine sono troppo grezzi per diventare un'API supportata sul lungo periodo, magari da inserire addirittura nelle GTK+;
   
2. se anche se ne scrivesse uno nuovo ed elegante, dovrà per forza seguire la politica del minimo comune denominatore, implementando solo quelle funzioni comuni tra di vari engine (risultando quindi decentemente monco).
   

La soluzione da lui proprosta è quindi supportare per la propria applicazione un solo engine per volta (a run time, o meglio a configure time, oppure tout court) come dipendenza aggiuntiva e parallela. Anche la strada scelta dalle QT 4.4 di incorporare WebKit non è percorribile, data la scarsità di risorse umane delle GTK+ e la quasi necessità di creare un quasi-fork per evitare dipendenze circolari (sempre parola di Alp Toker).

E con ciò cominciano, direbbero a Roma, i cazzi amari. Già perché sarebbe assurdo dire "nelle vostre applicazioni, se avete bisogno di una vista HTML, usate WebKit o Gecko o Gtkhtml, indifferentemente"; GNOME è un ambiente desktop, ma anche una piattaforma e non potremmo certo attrarre sviluppatori di terze parti con qualcosa di così sospeso nel giudizio.

Sarebbe opportuno dire, piuttosto, "il motore di rendering HTML scelto come dipendenza esterna ufficiale per GNOME è XXXXX, se poi ne volete usate un'altro fate pure, però abbiamo valutato e ponderato e XXXXX è cosa buona che fareste meglio a usare anche voi". Su che criterio, però, basare la scelta?

Lucertolone affamato

Di Gecko non si può che dirne bene. In fin dei conti è il nostro paladino che si insinua nel territorio dell'infedele e ne fa strage mozzando le teste e facendone zampillare il putrido sangue (OK, non so bene il perché di quest'immagine cruenta e fideistica, forse ultimamente ho giocato un po' troppo a Faith Fighter). Funziona, funziona bene, nell'ultimo rilascio funziona anche meglio, ha alle spalle uno sviluppo libero quasi decennale e una base utenti che dovrebbe essere il 20~25% dei naviganti mondiali (in perenne crescita?).

Con tutta questa "genuità e garanzia der consumatore" viene da chiedersi che si pone a fare il dubbio di cui sopra. Teniamoci Gecko, punto.

Beh, a essere proprio sinceri sinceri i suoi difettucci Gecko li ha, specie se lo si osserva non dal punto di vista dell'applicazione che quel 20~25% di cui sopra usa tutti i giorni, ma della libreria per sviluppare o abbellire le proprie applicazioni.

Il problema di fondo infatti non è tanto individuare un "well behaving" web browser da usare in GNOME, ma una libreria per permettere agli sviluppatori di applicazioni GTK+/GNOME di inserire contenuti di tipo HTML in modo facile e indolore, così come agli utenti di visualizzare e possibilmente editare tali contenuti in modo standardizzato, completo, stabile, sicuro, affidabile e rapido.

Da questo punto di vista le cose non sono così rosee: Gecko/Firefox infatti usa alcune tecnologie di GNOME e GTK+ per il suo porting in ambienti *NIX, ma in cambio non offre strumenti (leggi API e/o integrazione) adeguati. Un paio di commenti non miei:

Gecko e il lavoro sulle funzionalità di Gecko sono guidati per la maggior parte dal browser Firefox[...] e l'API per l'embedding di Gecko è rimasta non mantenuta e stagnante da lungo tempo; parola di Christian Persch (Epiphany developer).

Usando Gecko ho sempre avuto la sensazione di estrarre chirurgicamente pezzi di un'altra applicazione, invece di usare una libreria ben progettata; parola di Shaun McCance (Yelp developer).

Personalmente ho sempre avuto anche io la cattiva sensazione che la Mozilla Foundation sia troppo (o solo) interessata alle proprie applicazioni, come se Gecko nasca e muoia all'interno dei loro progetti e tutti gli altri (nel senso quelli che debbono scrivere un'applicazione che usi Gecko) farebbero meglio a usare XUL. Andatevi a leggere i changelog di Epiphany e controllate quante volte è si è dovuto rincorrere i cambiamenti di API, anche relativi alla stessa versione di Gecko. Oppure pensate al fatto che, non dico su Windows dove forse è normale, ma nelle varie distribuzioni GNU/Linux ogni applicazione che viene dalla Mozilla Foundation compila e installa la sua versione privata e forse linkata staticamente di libgecko, libnss, libnspr e via dicendo.

Bussola che strizza l'occhiolino

WebKit. O meglio WebKitGtk. Sembra la risposta a tutto quanto manca sopra. Una API che ricalca quella di GTK+/Glib/GObject, uso di tecnologie "native" come Cairo, Pango, Libsoup, GStreamer (e a breve gnome-keyring) ovunque sia possibile, una serie di obiettivi ampiamente condivisibili e la fresca ventata di freschezza che una novità porta sempre con sé. Senza dimenticare che, in quanto fork di KHTML ha anch'esso uno sviluppo quasi decennale.

Insomma, il fatto di essere pensato e sviluppato per essere solo un engine, senza che lo sviluppo sia trainato da un ingombrante browser di riferimento, lo rende ottimo candidato per tutte quelle applicazioni che necessitano di mostrare dei contenuti tipo HTML; inoltre la promessa di avere nell'immediato futuro dei cicli di rilascio semestrali con una stabilità delle API lo rende certo attraente per quelle applicazioni che non hanno risorse umane sufficienti a correggere i propri bug, implementare nuove funzioni e controllare se le API di Gecko sono cambiate senza che nessuno lo annunciasse.

Ora, bene inteso, non sto dicendo che è perfetto, anzi. Innanzitutto è un progetto giovane e probabilmente immaturo (almeno nella sua incarnazione per GTK+ e in confronto a Gecko), in secondo luogo è un progetto giovane e probabilmente immaturo (no, non mi sono incantato), in terzo luogo manca di un adeguato supporto all'accessibilità (sempre nella sua incarnazione per GTK+ e specie per tutte quelle cose tipo ARIA su cui Gecko ha lavorato nelle sua ultima incarnazione in stretto contatto con gli sviluppatori di Orca), in quarto luogo tutta la gestione del https:// e simili deve essere gestita dal browser (ma è una pecca? WebKit in fondo è solo un engine per html...), in quinto luogo non mi è ancora chiaro come e se funzionano i plugin tipo java o flash, in sesto, settimo e ottavo luogo, è un progetto giovane e ancora immaturo (tutti in coro: sono un vinile che si sta incantando, sono un buddista che ti sta gonghiando, sono una crema allora sto impazzendo, sono un bambino e faccio giro giro tondo, giro giro tondo...).

Faith Fighter

Se volete, ribaltando l'ottica, negli ultimi dieci anni lo sviluppo di "cose" relative al web ha visto come unico target mozilla/firefox/gecko: "Abbiamo mozilla, mozilla ci fornisce il web, ce lo fornisce libero, ce lo fornisce rispettoso degli standard, non ci serve null'altro".

Beh, non è più così. Non solo ora abbiamo WebKit, abbiamo anche una serie di sviluppatori che stanno manifestando esigenze che Mozilla non è (stato) in grado e non si è mai sforzato di risolvere: gli sviluppatori di Yelp e Devhelp hanno bisogno di una semplice vista html da inizializzare e gestire in 100 righe di codice, gli sviluppatori di Pidgin e di Empathy vorrebbero aggiungere un po' di vivacità nelle finestre di chat con un numero di righe di codice poco superiore, gli sviluppatori di Evolution potrebbero smetterla di sviluppare e mantenere Gtkhtml, gli sviluppatori di Epiphany desiderano concentrarsi sullo sviluppo della loro applicazione e delle funzioni che vogliono rendere disponibili.

Insomma, stiamo nel bel mezzo di una fase di crisi d'identità e visti i primi commenti direi che non appena WebKit verrà proposto come dipendenza esterna potrebbe scatenarsi una decente guerra di religione.

Io voglio bene a mozilla/gecko, è grazie a lui se in questi ultimi dieci anni ho potuto godermi tutto il porno che c'è sul web e so che attualmente epiphany-webkit non regge il confronto con epiphany-gecko.

D'altro canto, sin dalle prime apparizioni di Galeon/Epiphany, non sono mai stato tanto attaccato a Firefox (come applicazione a sé) forse perché, in quanto "sostenitore" di GNOME (utente e 1/8 di sviluppatore), ciò che voglio è un browser che sì funzioni, ma che sia anche ben integrato nell'ambiente, non solo rispettando delle varie linee guida per l'interfaccia, ma anche usando al meglio le tecnologie della piattaforma di sviluppo di GNOME e fornendone di sue con la medesima filosofia (primo esempio pratico: grazie a GConf e al lockdown fare un chiosco con Epiphany è semplice come impostare 3 o 4 chiavi a true, Firefox richiede, se non erro, un plugin esterno; secondo esempio pratico: a che mi serve scrivere codice per un password manager nel browser se ho già gnome-keyring e seahorse?).

Ora, da un lato abbiamo Gecko che funziona ottimamente, ma che è difficile da integrare, dall'altro WebKitGtk che è stato pensato proprio per essere integrato con facilità, ma che manca della necessaria maturità.

Il piatto è traballante, la scelta degli sviluppatori di Epiphany di usare solo WebKitGtk per la prossima release è coraggiosa (specie considerando che avviene in concomitanza la migliorata integrazione di Firefox in GNOME e tutto il lavoro sull'accessibilità svolto assieme al team di Orca), ma al tempo stesso è la scelta migliore che al momento potevano fare, per il loro progetto e forse per l'intero desktop. Una volta infatti approvato WebKit come dipendenza esterna ufficiale, ogni applicazione di e per GNOME potrà liberamente usarlo per i propri scopi e necessità e a quel punto, se effettivamente valido come sembra, potrà migliorarsi, "imporsi" e darci tante, tante soddisfazioni. In caso contrario, forse altre sei mesi di indefesso sviluppo potrebbero bastare. Chissà se basteranno anche a GtkMozEmbed per sparire del tutto o per essere adeguatamente aggiornato...

Colpo di coda

Visto che questo post è finito col tramutarsi in un j'accuse contro il metodo di sviluppo della Mozilla Foundation, aggiungiamo un altro tassello. Trattasi nello specifico di NSS ossia in Network Security Service.

Per la piattaforma GNU/Linux esistono diversi pacchetti che forniscono dei servizi crittografici, tra cui NSS, OpenSSL, Cyrus SASL, GnuPG, GnuTLS, OpenSSH e altri (kernel incluso). Tutti noi sappiamo che la varietà è cosa buona e bella, ma anche che, se la verità e nel diario, la varietà e nel divario.

Qual è il problema di tale divario? Ovviamente che a seconda di quali e quanti servizi crittografici le mie applicazioni hanno scelto, sarò costretto a ripetere N volte azioni come l'importazione di un certificato.

Non solo, pare che esista una cosa chiamata FIPS 140, una delle solite convalide da fare passare al proprio software per essere usato dal governo americano. Ovviamente tale FIPS 140 è diventata pietra di paragone e misura della qualità di un servizio crittografico. Altrettanto ovviamente è qualcosa che di tanto in tanto va rinnovata e che molto probabilmente richiede un esborso monetario.

Attualmente solo NSS è in una buona posizione con tale FIPS 140: OpenSSL ha avuto dei problemi di "rinnovo", GnuTLS non è mai stato convalidato.

Per ulteriori approfondimenti sulla questione, e sul perché potrebbe essere utile avere un solo servizio crittografico come altri sistemi (al solito Win e MacOS), consultate questa pagina.

Dov'è il problema? È che, al solito, compilare NSS come libreria esterna a Firefox è impresa destinata a fallire. Esiste un pacchetto con i sorgenti (rilasciati sotto licenza MPL, GPL e LGPL) ma in esso non vi è traccia di una infrastruttura per configurare, compilare e installare la libreria. Volete usare NSS? Bene, impazzite pure a ricreare tutta l'infrastruttura includendo il codice nella vostra applicazione e linkando staticamente, oppure compilatevi Firefox (2.0 però, la 3.0 non installa nulla che abbia a che vedere con lo sviluppo). E poi non venitemi a dire che la Mozilla Foundatio è amichevole con gli sviluppatori...

[1] mah, a me sono sempre stati un po' antipatici entrambi
[2] ma volete pagorarlo all'urlare "Fiamma!" e volare coperti da lingue di fuoco?
[3] IMHO ora e sempre costume nero, no, non quella schifezza che c'è nel film, ma questo.... anche se... quello del povero Ben Reilly....