Link alla notizia: http://www.hwfiles.it/news/google-chrome-web-audio-api-e-codice-c-c++_38569.html

Nella nuova versione stabile di Chrome Google ha messo a disposizione le nuove API per gestire contenuti audio. Introdotta anche la tecnologia NaCl per l'utilizzo di codice C/C++ direttamente nel browser

Click sul link per visualizzare la notizia.

La questione di NaCl, dal punto di vista del web, è un po' pericolosa perché, al contrario di quanto si prefissa il web (una resa uguale su ogni macchina) il codice da eseguire con NaCl dev'essere ottimizzato per ogni architettura.
Secondo buon senso, potrà essere usato solo da alcune applicazioni che abbiano bisogno di performance come l'aria.

Concordo, tra l'altro bisogna vedere questa sandbox quanto è sicura, con C++ si possono fare cose che magari riescono a superarla in modo più semplice rispetto alle tecnologie standard.

MaxArt in teoria usando un compilatore LLVM sarebbe possibile avere codice portabile tra diverse architetture, almeno in alcuni casi.

La questione di NaCl, dal punto di vista del web, è un po' pericolosa perché, al contrario di quanto si prefissa il web (una resa uguale su ogni macchina) il codice da eseguire con NaCl dev'essere ottimizzato per ogni architettura

Estremizzando questa giusta perplessità, mi domando: ma uno sviluppatore che intenda usare questa funzionalità dovrà fornire un eseguibile separato per ogni possibile architettura hardware/software su cui Chrome può essere utilizzato? L'accesso ai servizi del sistema operativo ospite avviene invocando direttamente le API del sistema operativo stesso, o tramite uno strato intermedio interno a Chrome?

Secondo buon senso, potrà essere usato solo da alcune applicazioni che abbiano bisogno di performance come l'aria

Sì ma se non si possono fare assunzioni a priori sull'hardware sottostante, il binario andrà compilato con ottimizzazioni e set di istruzioni in uso il più possibile conservativi, vanificando quindi l'ipotetico vantaggio di avere un eseguibile nativo. Mi vien da credere che in questo frangente, paradossalmente, un eseguibile gestito e compilato Just-In-Time come un .NET riesca a far meglio...

Ciao
Filippo

Quasi sicuramente per il primo punto hai ragione, al 99% essendo in una sandbox puoi accedere solo alle API esposte dal browser.

Per il secondo punto, secondo me, con LLVM si riesce ad ovviare al problema, ma bisogna vedere se è possibile usarlo.

Ci ho fatto la tesi triennale su NaCL...
Un anno fa il compilatore (che è una versione modificata di gcc) era disponibile unicamente per x86, quindi non saprei come vengono gestite le differenti architetture, cmq presumo ci siano differenti esguibili comilati per diverse archtetture, poi verrà usato solo quello corretto.

Il compilato è codice macchina senza particolari ottimizzazioni, questo perchè deve essere facilmente decompilabile a runtime... difatti il codice viene decompilato da NaCL (che è un plug in disponibile per tutti i browser) durante il download per controllare che non ci siano chiamate a sistema non permesse o codice malevolo in generale.

Nacl dovrebbe servire per scrivere il core delle web application, ovvero la parte più vicina al sistema operativo, tutte chiamate di sistema sono cmq mediate da nacl stesso, difatti si ha quasi un codice interpretato, mentre l'interfaccia potrebbe essere tranquillamente fatta in html/javascript. Questo unirebbe l'immediatezza delle interfacce web con la potenza di calcolo delle applicazioni native... è chiaro che sorgono svariate problematiche prima su tutte la sicurezza, però qui google ha svolto un'ottimo lavoro... ora resta da vedere se si diffonderà come tecnologia!

Nessuno ne parla ma lo sapete che nelle ultime versioni di Chrome è stato introdotto un bug che impedisce a tutte le applicazioni Flash che hanno un pannello di registrazione utente di scrivere un indirizzo email?
In pratica dopo aver digitato la chiocciola la tastiere di disabilita.
Il bug è stato per diverso tempo a carico di Adobe:
https://bugbase.adobe.com/index.cfm?event=bug&id=2966442
e ora è in mano a Chromium:
http://code.google.com/p/chromium/issues/detail?id=97193

Qualche esempio:
http://www.BuzzMath.com/Home
http://www.fattura24.com (andate in login per aprire la sezione Flash)

In pratica con questo scherzetto tutte le applicazioni Adobe Flash e Adobe Flex che hanno un pannello di registrazione che richiede un indirizzo email sono bloccate se eseguite da Chrome.
Un danno per il mercato pazzesco.

Fate circolare.... altro che release stabile :-)

ora resta da vedere se si diffonderà come tecnologia!

Se si diffonderà, immagino che anche tutti gli altri browser dovranno adeguarsi, altrimenti un utente sarà obbligato ad avere Chrome per poter sfruttare eventuali applicazioni basate su questa tecnologia.

Così su due piedi, sono molto scettico sulla possibilità di NaCl di affermarsi anche solo come standard de-facto. In un mondo che sta spingendo verso il cloud e verso l'hosting remoto delle applicazioni (quindi sempre meno esecuzione in locale), l'iniziativa NaCl mi sembra un clamoroso ritorno indietro nel tempo...

ehm... hai letto tutto quello che ho scritto?
google offre già nacl com plug in per firefox e ie!!!

Qualunque cosa pur di dire addio a javascript...

beh intanto puoi usare coffescript :D

Io concordo con Il_Baffo, cazzarola il javascript è un incubo...

Da quello che ho letto per adesso si deve compilare per la piattaforma target...
non dovete però badare alle idiosincrasie del SO o del processore sottostante, voi compilate usando le API che fornisce NACL che sono SEMPRE portabili e che sono appositamente limitate nelle operazioni che possono fare :D

Discorso diverso per PNACL a cui stanno lavorando... in questo caso si compila per una Macchina Virtuale e poi quando l'utente vuole eseguirla ecco che viene compilata al volo per il processore sottostante che sia ARM, X86, PPC...

P.S. jscript deve bruciareeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee!

Eccolo appunto, come pensavo stanno portando tutto su LLVM e compilano al volo... veramente eccezionale, a quel punto uno potrà programmare con un qualunque linguaggio, basta che emetta codice IF, poi sarà tradotto per l'architettura target.

Qualunque cosa pur di dire addio a javascript...

più flash che javascript, forse questo è il vero primo passo in tanti anni di web per avviare la progressiva sostituzione degli oggetti adobe flash, ovviamente ha senso solo se viene usato un layer astratto, un llvm appunto, ma a questo punto mi chiedo, come sarà questa tecnologia da un punto di vista prestazionale?, perché se dovremmo utilizzare la versione c++ degli applet, allora a malincuore mi tengo flash.

IMHO.

l'IF della LLVM viene compilato al volo, dopo è codice compilato, dopo questo passo è codice comparabile a quello generato da un compilatore standard con le medesime ottimizzazioni, quindi velocissimo.

l'IF della LLVM viene compilato al volo, dopo è codice compilato, dopo questo passo è codice comparabile a quello generato da un compilatore standard con le medesime ottimizzazioni, quindi velocissimo.

ah ho capito, convinto fosse pseudocodice eseguito da una virtual machine.