Google forgia l'alternativa ad ActiveX

Svelato un progetto open source che nei prossimi anni potrebbe consentire alle web application di accedere alla piena potenza delle CPU dei client, aprendo la strada ad applicazioni online più complesse e performanti

Roma - Coniugare i vantaggi forniti dalle web application, quali neutralità, portabilità e sicurezza, con i vantaggi tipici delle applicazioni desktop, primo fra tutti la capacità di sfruttare appieno la potenza di calcolo dei computer client. Questo, a grandi linee, l'obiettivo perseguito da Google con il nuovo progetto open source Native Client, di cui è appena stata rilasciata una prima versione di test.

Tecnicamente parlando, Native Client è una tecnologia che permette alle web application di eseguire codice x86 nativo sul client, superando le limitazioni tipiche dei linguaggi di scripting. Questa caratteristica fa sì che le applicazioni web possano accedere alla piena potenza della CPU locale, e agire in modo molto simile al software desktop tradizionale.

"I PC di oggi possono eseguire miliardi di istruzioni per secondo, ma le attuali applicazioni web possono accedere solo a una piccola frazione di questa potenza di calcolo", ha affermato Brad Chen, del Native Client Team di Google, in questo post. "Native Client è una tecnologia di ricerca, e l'obiettivo di questa release è mostrare tale tecnologia a ricercatori, esperti di sicurezza e community open source per ottenere il loro feedback e i loro contributi".
Chen ha spiegato che Native Client potrà essere utilizzato, ad esempio, per aggiungere ad un sito di photo-sharing degli strumenti di fotoritocco che consentano all'utente di modificare le proprie immagini senza lasciare il sito. "Oggi sarebbe possibile fornire tale funzionalità utilizzando una combinazione di JavaScript e di elaborazione server side. Questo approccio, tuttavia, richiede il trasferimento delle immagini dal server al browser e viceversa, e potrebbe rivelarsi così lento da scoraggiare l'utente", ha proseguito lo sviluppatore. "Con la possibilità di far girare in modo trasparente del codice nativo sulla macchina dell'utente, gli sviluppatori potranno implementare l'intero processo di elaborazione delle foto sulla CPU desktop, minimizzando in questo modo la quantità di dati trasferiti (le immagini rimangono infatti sul server, ndr) e le latenze".

Native Client si compone di un motore runtime, di un plug-in per i browser e di tool per la compilazione basati sul noto software open source GCC.

Qualcuno ha già definito Native Client l'alternativa open source alla tecnologia ActiveX di Microsoft, ma in realtà - sebbene le due tecnologie abbiano finalità simili - l'approccio di Native Client è molto differente da quello adottato da BigM, e per certi versi più simile al progetto Alchemy di Adobe.

Chen sostiene che Native Client non è stato pensato per sostituire le tecnologie web esistenti, come AJAX, Flash, JavaFX o Silverlight. "Riteniamo che gli sviluppatori possano usare questa tecnologia insieme ad altre per creare applicazioni che offrano un'esperienza più ricca e dinamica di quanto fosse possibile fino ad oggi".

Come ogni tecnologia che tenta di mettere a disposizione delle applicazioni web le risorse locali dei client, anche Native Client dovrà fare i conti con il fattore sicurezza: una web application capace di eseguire codice nativo sul client potrebbe infatti rivelarsi estremamente dannosa. Per scongiurare tale possibilità, Google ha spiegato che le applicazioni Native Client gireranno - come quelle Java - all'interno di una sandbox, e non potranno contenere certe sequenze di istruzioni. Il motore runtime sarà inoltre in grado di rilevare e bloccare in automatico ogni porzione di codice potenzialmente pericolosa, ma realizzare tutto rappresenterà una vera sfida per il progetto di Google: sfida che BigG spera di superare con l'aiuto della comunità.

Attualmente il plug-in di Native Client, scaricabile da qui, è compatibile con i browser Firefox, Safari, Opera e Google Chrome e con le versioni x86 di Windows, Linux e Mac OS X. Gli sviluppatori contano di portare presto il software anche su altre architetture hardware, quali ARM e PowerPC.

Il codice di Native Client è accompagnato dalla New BSD License.
120 Commenti alla Notizia Google forgia l'alternativa ad ActiveX
Ordina
  • Credo che il principale limite di questa idea sia il fatto che ogni applet da far girare sul client sia dipendente dall'hardware ospite.

    Java ha cercato di risolvere questo problema utilizzando un bytecode interpretato, ma nonostante tutto ha fallito l'obiettivo prefissato 'write once, run anywhere'.

    Se voglio indipendenza dalla piattaforma, devo per forza usare un linguaggio interpretato, e convincere gli utenti ad installare l'interprete sulla macchina ospite, con tutte le implicazioni legate ad un ulteriore software da tenere aggiornato (sicurezza, aggiornamenti, incompatibilità tra versioni - vedi Java).

    Se voglio prestazioni, non posso usare un linguaggio interpretato ma devo usare codice nativo, che dipende dalla macchina ospite (sia dal set di istruzioni della CPU che dall'hardware installato - GPU, processori crittografici, etc.), ma di ogni applet occorre rilasciare una versione per ogni piattaforma, e ci si andrebbe ad impelagare nel problema della disponibilità e della compatiblità dei device driver.

    Occorre inoltre tenere conto che ormai ci si può aspettare che qualsiasi cosa si voglia fare con un computer, questa debba poter fare anche con un telefono, un navigatore, etc.

    Una soluzione avrebbe potuto essere quella inventata dalla Transmeta e Linus Torvalds: CPU che possano tradurre il codice macchina di CPU diverse nel proprio codice nativo.
    In pratica si porterebbe il livello di interpretazione del codice a livello hardware e di microcodice.
    Ma occorrerebbe standardizzare il codice macchina di Internet, e comunque tale software girerebbe soltanto su hardware con queste capacità.

    Ci troviamo nella situazione in cui il browser sta diventando il sistema operativo, o per spararle meno grosse, deve comunque esporre al codice scaricato da Internet servizi del sistema operativo.

    Ma la volta che attraverso il browser fossero accessibili servizi di base forniti dal sistema (OpenGL, DirectX, filesystem, database, etc.), cosa si sarebbe inventato di diverso dalle attuali applicazioni da installare?
    OK, l'unica differenza starebbe nel fatto che l'applicazione non dovrebbe essere installata, ma in ogni caso sarebbe caricata, in qualche modo, nella cache degli applet e/o dei plugin del browser.

    Il fatto che l'idea arrivi da Google mi fa pensare che non gli sia più sufficiente il farsi consegnare i dati degli / dagli utenti, ma che cerchi anche di andarseli a prendere direttamente sulla loro macchine ...
  • > Credo che il principale limite di questa idea sia
    > il fatto che ogni applet da far girare sul client
    > sia dipendente dall'hardware
    > ospite.
    >
    > Java ha cercato di risolvere questo problema
    > utilizzando un bytecode interpretato, ma
    > nonostante tutto ha fallito l'obiettivo
    > prefissato 'write once, run
    > anywhere
    '.

    Già, che si è evoluto in: 'write once, debug everywhere'A bocca aperta

    > Una soluzione avrebbe potuto essere quella
    > inventata dalla Transmeta e Linus Torvalds: CPU
    > che possano tradurre il codice macchina di CPU
    > diverse nel proprio codice
    > nativo.

    Ma la fine che ha fatto transmeta, dovrebbe essere un'indizio sulla validità della soluzione...Triste

    > Ma la volta che attraverso il browser fossero
    > accessibili servizi di base forniti dal sistema
    > (OpenGL, DirectX, filesystem, database, etc.),
    > cosa si sarebbe inventato di diverso dalle
    > attuali applicazioni da
    > installare?

    O dagli activeX ?

    > Il fatto che l'idea arrivi da Google mi fa
    > pensare che non gli sia più sufficiente il farsi
    > consegnare i dati degli / dagli utenti, ma che
    > cerchi anche di andarseli a prendere direttamente
    > sulla loro macchine
    > ...
    Beh ci sono i sorgenti...Occhiolino
    non+autenticato
  • - Scritto da: pippo

    ...

    > > Il fatto che l'idea arrivi da Google mi fa
    > > pensare che non gli sia più sufficiente il farsi
    > > consegnare i dati degli / dagli utenti, ma che
    > > cerchi anche di andarseli a prendere
    > direttamente
    > > sulla loro macchine
    > > ...
    > Beh ci sono i sorgenti...Occhiolino

    Non parlavo di possibili furti di dati (in ogni caso la disponibilità dei sorgenti è la miglior garanzia che questo non accada).

    Mi riferivo invece alle (abili) politiche commerciali di Google che, offrendo ottimi servizi a costo zero, invoglia gli utenti ad utilizzarli (vedi GMail, Google Documents, etc.)
    In questo modo anche coloro che non veicolavano i propri documenti attraverso i servizi di Google (o comunque per i documenti che uno preferisce tenersi gelosamente sul proprio PC), esiste la possibilità per Google di 'correlarli' con altri documenti e servizi presenti on-line.
    Questo significa per esempio profilare meglio l'utente.

    Indipendentemente comunque dall'accesso o meno ai documenti dell'utente, questo è a mio parere un altro mattone della strategia di Google per rendere superfluo qualunque software (di base) non Google.
    A breve Windows non servirà più a nulla (ad un utente medio-basso): stanno già uscendo PC con Linux e browser firmware'izzati sulla motherboard, e questo significa poter utilizzare il PC (per le funzionalità di base) anche senza alcun sistema operativo, browser, client di posta, etc. commerciali.

    La volta che la Microsoft si perde il mercato di Windows e di Office e delle relative licenze di Upgrade, su cosa fonderà il proprio business?

    Lungi da me la presunzione di vedere più in là degli strateghi commerciali della Microsoft, ma a parer mio, mi sembra che Microsoft sia decisamente in ritardo con una politica di riconversione ad altri e più proficui obiettivi.
  • > Non parlavo di possibili furti di dati (in ogni
    > caso la disponibilità dei sorgenti è la miglior
    > garanzia che questo non
    > accada).
    >
    > Mi riferivo invece alle (abili) politiche
    > commerciali di Google che, offrendo ottimi
    > servizi a costo zero, invoglia gli utenti ad
    > utilizzarli (vedi GMail, Google Documents,
    > etc.)
    > In questo modo anche coloro che non veicolavano i
    > propri documenti attraverso i servizi di Google
    > (o comunque per i documenti che uno preferisce
    > tenersi gelosamente sul proprio PC), esiste la
    > possibilità per Google di 'correlarli' con altri
    > documenti e servizi presenti
    > on-line.

    penso che google abbia la potenzialità di farla grossa se realizzasse questo, non so come andrà a finire ma se l'obiettivo di Google è questo... ^_^

    > Questo significa per esempio profilare meglio
    > l'utente.
    >

    La legislazione italiana ha inventato lo studio di settore, anche punto informatico ogni anno invia il proprio studio di settore e questo per profilate meglio l'azienda nelle politiche governative e legislative sia di stato che di regione. Ma qui si tratta di utenti.

    > Indipendentemente comunque dall'accesso o meno ai
    > documenti dell'utente, questo è a mio parere un
    > altro mattone della strategia di Google per
    > rendere superfluo qualunque software (di base)
    > non
    > Google.
    > A breve Windows non servirà più a nulla (ad un
    > utente medio-basso): stanno già uscendo PC con
    > Linux e browser firmware'izzati sulla
    > motherboard, e questo significa poter utilizzare
    > il PC (per le funzionalità di base) anche senza
    > alcun sistema operativo, browser, client di
    > posta, etc.
    > commerciali.

    e questo è un passo avanti ma purtroppo non è quello definitivo, del resto esistono già sistemi di questo tipo e già un cellulare è in grado di fare questo. Comunque sia questa politica a mio parere costringerà Microsoft a rilasciare un Windows base gratuito più o meno con le stesse caratteristiche, se non lo fa, non dico che si taglia fuori dal mercato ma di certo rinuncia ad un bel pezzo mercato.

    >
    > La volta che la Microsoft si perde il mercato di
    > Windows e di Office e delle relative licenze di
    > Upgrade, su cosa fonderà il proprio
    > business?
    >


    > Lungi da me la presunzione di vedere più in là
    > degli strateghi commerciali della Microsoft, ma a
    > parer mio, mi sembra che Microsoft sia
    > decisamente in ritardo con una politica di
    > riconversione ad altri e più proficui
    > obiettivi.

    Comunque non la farei così tragica, qualche volta dovrà pure crollare da qualche parte? ^______^
  • - Scritto da: andy61
    > Credo che il principale limite di questa idea sia
    > il fatto che ogni applet da far girare sul client
    > sia dipendente dall'hardware
    > ospite.

    scherzosamente un www.tizio.cavolfiore non basta più, x86ww.tizio.cavolfiore
    A mio parere questa è una cosa teorica che è stata messa nella pratica ma non è stata poi in grado di raggiungere gli obbiettivi prefissati perché evidentemente non è possibile e non credo per motivi tecnici.

    >
    > Java ha cercato di risolvere questo problema
    > utilizzando un bytecode interpretato, ma
    > nonostante tutto ha fallito l'obiettivo
    > prefissato 'write once, run
    > anywhere
    '.
    >

    Java mi ricorda il gwbasic a grandi linee ma la società comunque era strutturata in modo diverso, ma è chiaro che il codice interpretato rende disponibile solo una piccola parte di risorse, la maggior parte sono usate dall'interprete. Oltre a java c'è jamba, il j++ e altri derivati che hanno reso la confusione.

    > Se voglio indipendenza dalla piattaforma, devo
    > per forza usare un linguaggio interpretato, e
    > convincere gli utenti ad installare l'interprete
    > sulla macchina ospite, con tutte le implicazioni
    > legate ad un ulteriore software da tenere
    > aggiornato (sicurezza, aggiornamenti,
    > incompatibilità tra versioni - vedi
    > Java).

    Non necessariamente... su questo non sono d'accordo, in realtà java è solo il secondo (non il primo) tentativo, il linguaggio non deve essere per forza intepretato ed in realtà dei fatti si è già raggiunto questo tipo di obbiettivo ma evidentemente è l'obbiettivo che è sbagliato anche se la tecnica e anche la standardizzazione è riuscita egregiamente.
    Lo standard ANSI C e C++ per gli oggetti ha accumunato comunque gran parte della programmazione, questo standard si trova anche per microprocessori diversi e di diversa natura. Basterebbero comunque delle operazioni a mio parere banali, si scarica l'applet o listato in varie forme, il compilatore in locale lo compila e magari lo ricompila ad ogni aggiornamento, la macchina locale esegue codice nativo con tutta la performance. Ma anche se questo funzionasse è l'obbiettivo che una volta raggiunto questo fallisce. La dipendenza da questo (mi sembra di parlare di oggetti di programmazione ^_^) è da ritrovarsi nel mercato ed è il mercato che come ultimo può fare anche decadere idee e progetti ottimi ma questi devono essere in linea comunque con la tendenza di mercato.

    >
    > Se voglio prestazioni, non posso usare un
    > linguaggio interpretato ma devo usare codice
    > nativo, che dipende dalla macchina ospite (sia
    > dal set di istruzioni della CPU che dall'hardware
    > installato - GPU, processori crittografici,
    > etc.), ma di ogni applet occorre rilasciare una
    > versione per ogni piattaforma, e ci si andrebbe
    > ad impelagare nel problema della disponibilità e
    > della compatiblità dei device
    > driver.
    >
    l'inteprete ciuccia cicli di clock, deve leggere e memorizzare, eseguire istruzione e ciuccia anche parecchia memoria, per il resto sono d'accordo

    > Occorre inoltre tenere conto che ormai ci si può
    > aspettare che qualsiasi cosa si voglia fare con
    > un computer, questa debba poter fare anche con un
    > telefono, un navigatore,
    > etc.
    >

    Questa è la tendenza di mercato...

    > Una soluzione avrebbe potuto essere quella
    > inventata dalla Transmeta e Linus Torvalds: CPU
    > che possano tradurre il codice macchina di CPU
    > diverse nel proprio codice
    > nativo.
    > In pratica si porterebbe il livello di
    > interpretazione del codice a livello hardware e
    > di
    > microcodice.
    > Ma occorrerebbe standardizzare il codice macchina
    > di Internet, e comunque tale software girerebbe
    > soltanto su hardware con queste
    > capacità.

    Questo sarebbe anche facile da realizzare anche su hardware che non prevede queste capacità, sarebbe come comprare il coprocessore matematico (calcoli in virgola mobile) e installarlo, per esempio installando un'interfaccia tra microprocessore e scheda madre.
    Si più comunque standardizzare il codice internet, ci si riesce ma questo sfuggie e scappa via, prima o poi... resta comunque importante avere una base di standard ma il mercato per non stagnizzare fa fuori questo standard, i motivi sono strettamente commerciali e anche non, per quanti sforzi si possa fare per rendere uno standard è lo stesso mercato che non vuole morire sotto lo standard, come del resto è normale e coerente che sia così.

    >
    > Ci troviamo nella situazione in cui il browser
    > sta diventando il sistema operativo, o per
    > spararle meno grosse, deve comunque esporre al
    > codice scaricato da Internet servizi del sistema
    > operativo.
    >

    Clientela pretenziosa... ^___^, ma questa è l'anima per cui il settore è in evoluzione, si cerca semplicemente di capire che cosa vuole la clientela... ^_^

    > Ma la volta che attraverso il browser fossero
    > accessibili servizi di base forniti dal sistema
    > (OpenGL, DirectX, filesystem, database, etc.),
    > cosa si sarebbe inventato di diverso dalle
    > attuali applicazioni da
    > installare?

    mmmm..... e la differenza delle estensioni multimediali? X86 standard è un conto ma poi anche li le diverse case si differenziano in qualche cosa.

    > OK, l'unica differenza starebbe nel fatto che
    > l'applicazione non dovrebbe essere installata, ma
    > in ogni caso sarebbe caricata, in qualche modo,
    > nella cache degli applet e/o dei plugin del
    > browser.
    >
    > Il fatto che l'idea arrivi da Google mi fa
    > pensare che non gli sia più sufficiente il farsi
    > consegnare i dati degli / dagli utenti, ma che
    > cerchi anche di andarseli a prendere direttamente
    > sulla loro macchine
    > ...

    I dati valgono molto, certi dati valgono molto di più delle linee di programma che realizzo io (ce vuole poco ahahahahhahaha), ma è in questa crisi economica che i dati valgono ancora molto di più, statisticamente diminuiscono le pubblicità d'elite (televisive e giornalistiche) ed aumentano quelle fatte porta a porta... è di certo un piatto appetitoso per la sopravvivenza... psicologia indirizzo pubblicitario magari è in grado di dare una risposta.
  • > La dipendenza da questo (mi sembra di
    > parlare di oggetti di programmazione ^_^) è da
    > ritrovarsi nel mercato ed è il mercato che come
    > ultimo può fare anche decadere idee e progetti
    > ottimi ma questi devono essere in linea comunque
    > con la tendenza di
    > mercato.

    Che pa@@e con sto mercato, guarda cosa sta succedendo ai campioni del libero mercato!!!A bocca aperta
    non+autenticato
  • - Scritto da: pippo
    > > La dipendenza da questo (mi sembra di
    > > parlare di oggetti di programmazione ^_^) è da
    > > ritrovarsi nel mercato ed è il mercato che come
    > > ultimo può fare anche decadere idee e progetti
    > > ottimi ma questi devono essere in linea comunque
    > > con la tendenza di
    > > mercato.
    >
    > Che pa@@e con sto mercato, guarda cosa sta
    > succedendo ai campioni del libero mercato!!!
    >A bocca aperta

    c'è chi sale e c'è chi scende, l'importante che faccia botta quando cade o le prende.

    Hai ragione pippo... sto facendo due @@ così... sto mercato a rotto!!

    Così, tu, pippo, disegnami la strada, illumina ciò che i miei passi calpestano ogni giorno, sarò i tuoi passi e la tua ombra d'affanno, non più campioni atterrati di antichi splendori decaduti nella Java terra ormai dal sapor surreale... disegna a me comune mortale la via d'inverno per aspettare il C++ che è sole d'estate.

    @@

    :)
  • > > Che pa@@e con sto mercato, guarda cosa sta
    > > succedendo ai campioni del libero mercato!!!
    > >A bocca aperta
    >
    > c'è chi sale e c'è chi scende, l'importante che
    > faccia botta quando cade o le
    > prende.

    Si, come i costruttori di auto e le banche, è proprio il caso: "son tutti gay col c@@o degli altri"A bocca aperta
    non+autenticato
  • - Scritto da: pippo
    > > > Che pa@@e con sto mercato, guarda cosa sta
    > > > succedendo ai campioni del libero mercato!!!
    > > >A bocca aperta
    > >
    > > c'è chi sale e c'è chi scende, l'importante che
    > > faccia botta quando cade o le
    > > prende.
    >
    > Si, come i costruttori di auto e le banche, è
    > proprio il caso: "son tutti gay col c@@o degli
    > altri"
    >A bocca aperta

    e bhè... funzica sempre così ^_^ e questo ragazzi miei è un vero e proprio standard a codice nativo x86bastardi, e questo si che funziona veloce!! hihihihihihih
    :D
  • Da alcuni precedenti commenti capisco che l'articolo non è chiaro ai più.
    Ma PI non dovrebbe essere una rivista di Informatica?
    E allora come mai così tanti commenti fuori luogo?

    Ho sentito parlare di diverse tecnologie (Ajax and Co.) che nulla hanno a che vedere col il tema trattato.

    Quando si parla di interazione con il Desktop si intende un vero e proprio flusso tra applicazione web e processore (ivi comprese, soprattutto, operazioni con i file, eventuali db locali etc...) quindi di esecuzione di codice in locale.
    Attualmente per un'applicazione web non è possibile accedere, per esempio, a file salvati in locale sul client, mentre si può ovviare attraverso l'uso di ActiveX (ecco perchè sono pericolosi), il tutto senza dover installare un server sulla macchina.

    Disponibile per chiarimenti.

    Reputo la cosa pericolosa (cavolo, si sta facendo tanto per debellare gli ActiveX!...)
    -----------------------------------------------------------
    Modificato dall' autore il 10 dicembre 2008 13.28
    -----------------------------------------------------------
    H5N1
    1641
  • - Scritto da: H5N1

    > Ma PI non dovrebbe essere una rivista di
    > Informatica?

    Tu dici ?
    Dici che a leggerlo si direbbe ???
    krane
    22544
  • Semplice, nei commenti si tirano fuori dubbi e si discute.

    Si trolla anche, ma si hanno anche spunti interessanti.


    Se non ti sta bene, fermati a leggere la notizia, e vai su altri lidi per eventuali discussioni.

    Qui non troverai trattati tecnici e analisi dettagliate.
  • Beh però se la cosa non è chiara, se l'argomento non si conosce o non si è capito bene, sarebbe giusto non sparare sentenze o fare precisazioni che centrano poco.

    Si snellirebbero i commenti, il sito sarebbe più fruibile e più pertinente ed interessante.
    non+autenticato
  • Anch'io vorrei un mondo senza guerre e dove tutto funziona bene...

    I commenti di PI sono liberamente utilizzabili, non c'è un premio per chi è più bravo o tecnico, è una specie di "bar" insomma, e come tale deve essere preso. È un posto dove si fanno discussioni tecniche, dove persone con un diverso grado di competenza di confrontano, e dove si trolleggia un po' ridendoci su.


    Ci sono posti più pertinenti se ti serve una discussione più seria, alcuni anche a pagamento dove hai un servizio di risposte più sofisticato e dettagliato.


    Dopotutto anche per i commenti, uno lo fa perchè li va, non perchè è pagato o perchè deve fornire un servizio a tutti. Per quello tanto vale che cerchi su altri lidi.

    Anche il contributo personale conta. È inutile saltare fuori ogni morte di papa e reclamare, se poi di proprio non si fa niente.
  • Mi limitavo a dare delle spiegazioni senza evitare, comunque, qualche critica ai commenti.
    H5N1
    1641
  • Probabilmente la sto sparando davvero grossa, ma se si cerca di avere programmi che girano bene anche in locale, non basta AJAX e simili? (come Google Apps).

    E magari un interfaccia standard, dove comunicando con il browser, ci pensa lui a gestire del codice che gira in locale? (es. un estensione).

    Così l'applicazione web rimane neutrale.
  • no, non c'azzecca un tubo.
    non+autenticato
  • Che c'entra AJAX?
    non+autenticato
  • Il problema era avere applicazioni che girano bene in locale? (quindi niente lentezza da parte della gui nel browser?)
  • Ma non si risolve, perché un'applicazione AJAX aumenta il traffico con il server e le operazioni vengonom in ogni caso, eseguite sul server, non sul client.
    non+autenticato
  • Ha un vantaggio: gira su qualunque browser supportato, e non richiede l'esecuzione di codice nativo.

    A me sembra che hanno fatto un passo indietro.
  • > Ha un vantaggio: gira su qualunque browser
    > supportato, e non richiede l'esecuzione di codice
    > nativo.
    >
    > A me sembra che hanno fatto un passo indietro.
    Quale parte di prestazioni ed accesso diretto alla CPU non ti è chiaro?A bocca aperta
    non+autenticato
  • Quale parte di "gira ovunque" non ti è chiara?Occhiolino

    Non tutti lavorano con PC x86.
  • > Quale parte di "gira ovunque" non ti è chiara?Occhiolino
    >
    > Non tutti lavorano con PC x86.
    O certo windows, linux, e macosx sono solo una piccola frazione del mercato!
    L'unica cpu degna di nota è l'arm, ma date le differenze di archittettura, vedo molto più semplice una bella ricompilazione del tuo codice.Occhiolino
    non+autenticato
  • Mmhh... dici che non rischia che ci si concentri solo su x86, e gli aggiornamenti per gli altri rimangono ... bloccati?

    Se fanno le cose come si deve, beh, allora potrebbe andareA bocca aperta

    Ma il rischio è grande... c'è ancora tempo e chissà cosa tirano fuori quelli di googleOcchiolino (il piano diabolico per conquistare il mondo)..
  • il piano è semplicemente svuotare il sistema operativo....

    se non puoi batterli commercialmente rendi il loro software inutile

    google sta semplicemente facendo terra bruciata intorno ai formati proprietari, rendendoli inutili

    ti serve un'applicazione di fotoritocco? perchè usarne una solo per windows, usane una cross-platform che gira su NaCl

    così facendo al sistema operativo resterà solo il compito di far funzionare l'hardware ed ospitare un browser

    insomma una cosa tipo SplashTop basta e avanza per tutti gli usi
    non+autenticato
  • L'obiettivo del web era mica di essere utilizzabile da qualunque apparecchio che permetta l'accesso in rete?

    Non credo che il W3C sia molto contento di questa "novità"...
  • - Scritto da: Brenji Ahiai
    > L'obiettivo del web era mica di essere
    > utilizzabile da qualunque apparecchio che
    > permetta l'accesso in
    > rete?
    >
    > Non credo che il W3C sia molto contento di questa
    > "novità"...

    Dipende... ci sono applicazioni per cui semplicemente l'HTML e javascript non bastano. Senza contare le innumerevoli applicazioni Intranet che richiedono accessi speciali alla macchina dell'utente... ti faccio un esempio... supponi che stai sviluppando un'applicativo per la firma digitale gestita via WEB (perché i documenti che firmi vanno processati secondo varie fasi da varie persone via WEB e ognuno deve poterli firmare ad esempio). Devi accedere alla SmartCard dell'utente, ovviamente i dati che processi durante la firma è bene rimangano sul PC dell'utente [non è bello trasmettere il PIN della Smartcard di firma via WEB visto che è un oggetto ufficiale e chiunque ce l'abbia e sappia il tuo PIN ha praticamente in mano la tua firma legalmente riconosciuta], quindi tutte queste operazioni le fai in locale. Ora... vuoi mettere poter distribuire un'applicazione che parte automaticamente via WEB come fa Java e che non serve che aggiorni su ogni client della tua Intranet ad ogni singola versione/bugfix/ecc. e che l'utente non deve ricordarsi di aggiornare?

    Insomma, bisogna anche vedere come questa tecnologia è usata prima di giudicarla, oramai moltissime applicazioni funzionano via WEB perché i vantaggi dell'avere il tuo gestionale via WEB raggiungibile magari dal PC di casa o varie sedi distaccate, oppure accedere ai dati dei tuoi clienti senza doverteli copiare sul portatile (con conseguente rischio di furto), oppure ancora semplicemente poter aggiornare tutte le postazioni della tua impresa con 100 PC sparsi in varie sedi senza dover ripassare PC per PC sono palesi.

    Hai ragione quando dici che usata male questa tecnologia è un danno, come è un danno usare Java senza un motivo valido su applicazioni che potrebbero essere tranquillamente html/javascript-only... però ci sono dei casi come quelli che ho citato in cui avere una tecnologia alternativa a Java potrebbe risultare molto utile. Poi ogni sviluppatore sceglie cosa usare in base alle sue necessità e al software che ha in mente.
  • Cavolo, ma ora ti lancio una provocazione.

    E possibile fare un sistema "generale" per accedere a certo hardware, ma lasciando l'applicazione che gira sul web indipendente dalla piattaforma?

    In pratica ci sarebbe un modo per accedere a componenti locali (e quindi codice x86 per esempio) ma l'applicazione web rimane sempre neutrale.

    O magari l'ho sparata grossa ed è già cosi...
  • > E possibile fare un sistema "generale" per
    > accedere a certo hardware, ma lasciando
    > l'applicazione che gira sul web indipendente
    > dalla
    > piattaforma?
    >
    > In pratica ci sarebbe un modo per accedere a
    > componenti locali (e quindi codice x86 per
    > esempio) ma l'applicazione web rimane sempre
    > neutrale.
    >
    > O magari l'ho sparata grossa ed è già cosi...
    Si MOLTO grossaA bocca aperta
    Ti consiglio questo linguaggio di programmazione:
    http://research.microsoft.com/projects/boku/
    non+autenticato
  • BelloOcchiolino ma non vedo cosa c'entra XNA con il web.

    Forse volevi parlarmi di Silverlight?A bocca aperta
  • > BelloOcchiolino ma non vedo cosa c'entra XNA con il web.
    >
    "The language is simple and entirely icon-based"
    Per venire incontro alle tue ridotte capacitàImbarazzato
    non+autenticato
  • Che simpaticoneOcchiolino

    Non sono afferrato di web, sono un "poveretto" che ha 10 anni di esperienza in C e si diletta con linguaggi tipo Haskell e PythonOcchiolino

    Ma mai potrei competere con uno sapiente come teA bocca aperta l'HTML 4.01 è davvero troppo difficile per me, credo che punterò quel linguaggio che mi dici tu ... Rotola dal ridere
    -----------------------------------------------------------
    Modificato dall' autore il 10 dicembre 2008 11.01
    -----------------------------------------------------------
  • > Non sono afferrato di web, sono un "poveretto"
    > che ha 10 anni di esperienza in C e si diletta
    > con linguaggi tipo Haskell e Python
    >Occhiolino
    >
    E chi parlava di web? Era la tua sparata grossa sul modo di accedere all'hardware ad essere in discussione.
    E detto da un programmatore C è proprio una enorme ca@@ata!
    P.S. io ne ho 20 anni di esperienza in C
    non+autenticato
  • Cioe, per te sarebbe una cazzata il fatto di:

    1. Avere un programma web, che usa delle API standard definite a priori ed indipendenti dall'OS...

    2. Avere un browser supportato

    3. Avere un componente aggiunto al browser che accetta i comandi "neutrali" del programma web, ed esegue in locale il codice nativo, ripassando tramite browser i dati.



    A me sembra sensato, mentre google mi dà l'idea che vuole rendere l'applicazione web completamente x86, quindi legata alla piattaforma.

    Però tu con i tuoi 20 anni di esperienza, non hai ancora detto niente di tecnico.
  • > 3. Avere un componente aggiunto al browser che
    > accetta i comandi "neutrali" del programma web,
    > ed esegue in locale il codice nativo, ripassando
    > tramite browser i
    > dati.
    C'è già si chiama GCCA bocca aperta
    non+autenticato
  • GCC è solo un compilatore. Rotola dal ridere

    Manca tutta la parte che è legata al browser.

    Ma rischia quindi (ovviamente) di essere una cosa dipendente sempre dal browser.


    Ti immaginiA bocca aperta i casini come tempo fa? Dove c'era chi supportava più cose o meno, e bug che possono permettere la scalata dei permessi?

    Non credo siano così stupidi, ma per quello che vedo ora, non mi convince del tutto.
  • Non credo sia la strada giusta, trovo molto più sensato gli applet java, o come preferirei un incorcio tra le WPF e codice .net lato client.... questi mi sembrano i soliti accrocchi ....
    non+autenticato
  • ma perchè wpf e il codice .net non fanno la stessa cosa e nello stesso modo??
    non+autenticato
  • Mamma mia, quindi vi aspettate che l'intero web giri su applet java e .net? Brrrr.... "che fetenzia" [cit.]

    Ragazzi, ci sono altre teconologie la fuori! Svegliatevi!

    O credete di essere arrivati al culmine della cultura Web-Informatica?

    Per quel che mi riguarda ritengo Java un linguaggio non adatto alle applicazioni Web.

    ...e ne ho provati tanti...

    .net... figuriamoci, un suo surrogato...
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
1 | 2 | 3 | Successiva
(pagina 1/3 - 12 discussioni)