Gli ultimi rilasci di Chrom* includono il Native Client (NaCl) per tutti i canali di sviluppo e Nokia ha intenzione d’elevare il supporto di Qt4 e Qt5 per la creazione di applicazioni “native” sul browser di Google. Il livello di maturazione è pressoché identico per entrambi i rami delle librerie. I risultati arriveranno nel 2012.
Benché il NaCl sia un progetto open source, la soluzione è ancora limitata a Chrom*. L’obiettivo degli sviluppatori di Qt è dare la possibilità d’utilizzare le librerie nelle applicazioni web, come avviene di norma sulle applicazioni “native”. Il porting del progetto in Qt5 prosegue in questa direzione. C’è un problema col backend.
Siamo alle solite, insomma: Chrom* utilizza WebKitGtk, mentre Qt provvede al mantenimento di QtWebKit — appena aggiornato alla versione 2.2.1 con il rilascio di Qt 4.8.0. La perfetta integrazione col NaCl prevederebbe l’utilizzo dello stesso backend. Ad esempio, sarebbe interessante un’implementazione del NaCl di Google su Rekonq.
Andrea Diamantini – l’ideatore di Rekonq – all’indomani della proposta di GNOME per Epiphany ha dimostrato la possibilità d’integrare le applicazioni web sul proprio browser. È un progetto sperimentale, che non prevede l’esecuzione di codice “nativo”. Se adottasse il NaCl di Google, invece, potrebbe sfruttare i progressi delle Qt.
La direzione di Qt non è limitata a Linux. Se Safari includesse il NaCl di Google, infatti, le librerie potrebbero aiutare le applicazioni “native” anche su Mac OS X e Windows. Al momento, lo sviluppo per i browser predilige le applicazioni web: il 2012 dovrebbe abbattere la differenza tra i due approcci, ma le soluzioni divergono.
Intel, dal canto suo, preferisce migliorare le applicazioni web con River Trail anziché permettere l’esecuzione di codice “native” sul browser. Opera e Mozilla sono sulla stessa linea d’onda. Nokia sembra essere la prima a credere davvero nella soluzione di Google e Qt5 avrà un ruolo fondamentale, nell’adozione di NaCl per WebKit.
Via | Phoronix
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
abral
26 dic 2011 - 14:14 - #1Questa volta avevo capito che l’articolo era di Federico già dal titolo…
Comunque meglio le applicazioni web, meglio evitare il più possibile il codice nativo. L’unica utilità di NaCl potrebbe essere il riuso di codice già esistente, ma esistono progetti come Emscripten che “traducono” applicazioni native in applicazioni web, meglio puntare su questi!
Henryx
26 dic 2011 - 14:26 - #2Il problema delle applicazioni web e` sempre lo stesso: nonostante i progressi fatti, sono decisamente limitate rispetto ad applicazioni native. Vedremo come si evolvera` questa cosa, anche se secondo me un buon approccio erano le applet Java e Java Web Start
Enrico
ri.p
26 dic 2011 - 19:22 - #3Chrom* non usa WebKitGtk, ma direttamente webkit. WebKitGtk è il port di webkit per il toolkit gtk+.
abral
27 dic 2011 - 01:59 - #4@Henryx:
non direi che sono limitate. Con le ultime API sviluppate da Mozilla si può fare praticamente tutto (http://johnhammink.blogspot.com/2011/11/lets-have-look-at-some-recently-landed.html e https://hacks.mozilla.org/2011/12/gaming-and-the-mozilla-labs-apps-project/).
Salvare files, accedere a dispositivi come gamepad, accedere a dispositivi di acquisizione immagini come una telecamera, non mi viene in mente nulla che manchi. L’unica cosa è la possibilità di effettuare connessioni P2P, che verrà sviluppata con WebRTC.
barra
27 dic 2011 - 13:51 - #5@abral
Ok, le api di mozilla possono fare di tutto ma il problema è quanto è necessario investire per fargli fare quello che mi serve.
Oggi esistono giochi e applicativi che possono essere portati su browser grazie alle NaCl con un investimento minimo (vedi Bastion, un gioco sviluppato con unity3d e mono). Il successo di NaCl sarà dato proprio da questo fattore: sviluppo una volta ed eseguo ovunque.
Gnimag
27 dic 2011 - 14:39 - #6A parte il titolo che questa volta data l’elevata steganografia mi ha spinto a leggere l’articolo e poi a decodificarlo attraverso i commenti.
A mio avviso usare api proprietarie seppur di propietari come mordilla o magilla, non è migliore di adottare lingiaggi per realizzare applicazioni flex o silverlight.
La cosa che ancora oggi non mi torna, è
Si vende che HTML5 è il futuro, ma alla fine è un gran casino di javascript e qualche nuovo tag, dove concetti necessari alla realizzazione di reali applicazioni business sono veramente lontani la standardizzazione di concetti come interfacce per classi portano ad avere una metodologia autonoma ed imposta dal team.
Questa magnifica compatibilità tra i browser html5 oriented è lontana dal divenire una realtà anzi , ognuno implementa a piacere. Almeno con flash scrivo una volta ed è il plugin a garantire l’uniformità, se non lo fa so chi è la causa, qua si parte già dicendo, ognuno fa un po come gli pare, tant’è che ci sono in molti sistemi di javascript librerie per la compatibilità, spesso non completamente funzionanti.
Mha sembra che ci siano tante idee e questo dimostra che la materia è alo culmine della sua attenzione però in uno stadio embrionale.
abral
28 dic 2011 - 02:52 - #7@barra:
Guarda ad esempio con Emscripten cosa è possibile portare in JavaScript da C++: https://github.com/kripken/emscripten/wiki. Secondo me questo è il futuro, non ancora un altro plugin con codice nativo, che può sempre avere problemi di sicurezza (sicuramente di più di codice JavaScript).
@Gnimag:
ma le API implementate da Mozilla non sono proprietarie. Alcune sono già standard web, altre sono ancora in via di sviluppo e in via di standardizzazione. Questo significa che tutti i browser le supporteranno, non c’è nulla di proprietario :D
Comunque per le API in via di sviluppo è normale che ci siano discordanze tra i vari vendor, questo è proprio ciò che le fa sviluppare verso quello che saranno in futuro. Gli sviluppatori devono putroppo aspettare che diventino standard prima di utilizzarle, oppure accontentarsi, nell’attesa, delle librerie che “nascondono” le differenze.
Gnimag
28 dic 2011 - 14:48 - #8C’è una marea di cose open e standardizzate, e faccio un esempio su tutti html che gestite da illuminate fondazioni dovrebbero essere uniformi come interpretazioni, per tutti, ma il risultato è una miriade di difformità proprio perchè chi si occupa della standardizzazione, non si occupa della bontà di implementazione, questo purtroppo non è risolvibile e nonostante le buone intenzioni queste situazioni non avantaggiano nessuno dal programmatore che spenderà più tempo nell’adattarsi alle varie versioni di browser per restare sul mercato perchè sia mai che si realizzi una applicazione non ie4 compatibile, all’acquirente che spenderà di più poichè è costato fare una versione interoperabile ed avrà un prodotto non uniforme a seconda del sistema usato.