Opera mette il turbo a modem e cellulari

La prossima versione del famoso browser commerciale integrerà il supporto ad una tecnologia che promette di velocizzare drasticamente la navigazione sul Web, specie per gli utenti di connessioni a 56 Kbps o GPRS

Oslo - Opera all'assalto: la prossima versione del suo browser promette di rendere assai più rapida la navigazione se ci si connette con i tradizionali dial-up o con connessioni wireless non particolarmente performanti.

Assediata da una competizione sempre più serrata del mondo open source, Opera Software sta da tempo cercando di distinguere il proprio browser dalla "massa" di software analoghi integrandovi tecnologie inedite o dedicate ad una precisa nicchia del mercato. E l'ultima trovata, sostiene la softwarehouse norvegese, consentirà di velocizzare l'uso del web fino a sei volte rispetto ad oggi.

L'effetto "turbo" non dipenderà da un nuovo e miracoloso motore di rendering, ma dal supporto di una soluzione sviluppata da SlipStream Data per gli ISP, che è capace di comprimere e ottimizzare in tempo reale i dati che transitano fra il provider e l'utente. SlipStream afferma che la propria tecnologia, già adottata da 900 ISP di tutto il mondo, rappresenta nientemeno che "il più significativo progresso tecnologico nella compressione lossless dei dati degli ultimi 20 anni": gli algoritmi utilizzati, che comprimono i dati in tempo reale e non necessitano di buffer, vengono infatti definiti nettamente più efficienti di quelli adottati fino ad oggi da certi ISP.
Su stessa ammissione di Opera Software, gli utenti di connessioni a larga banda (xDSL, cavo, satellite, ecc.) beneficeranno poco o nulla della tecnologia di SlipStream: dove questa può fare davvero la differenza, infatti, è sulle connessioni più lente, come quelle analogiche a 56 Kbps o quelle fornite oggi dalle reti cellulari (GSM, GPRS, EDGE, UMTS). Perché ciò avvenga, sia il client (in questo caso Opera) sia il server (quello che fornisce il servizio di connettività all'utente) devono supportare la tecnologia di SlipStream: al momento nessun provider italiano ne ha ancora annunciato pubblicamente il supporto.

"Nei prossimi cinque anni ci sarà ancora un significativo numero di utenti di Internet con connessioni a banda stretta, sia dial-up che mobili", ha dichiarato David Snyder, vice president di Opera Software. "Inizialmente la nuova versione di Opera sarà destinata agli utenti desktop, ma presto ne rilasceremo versioni per altre piattaforme, tra cui i telefoni cellulari".
TAG: mondo
22 Commenti alla Notizia Opera mette il turbo a modem e cellulari
Ordina
  • Finalmente qualcuno incomincia a pensare anche alle povere vittime del Digital Divide.

    Per me che navigo a 56k, navigare 6 volte più veloce mi sembrerebbe un miracolo! Ma funzionerà? Come si fa a comprimere ulteriormente un JPG?

    Stiamo a vedere e speriamo.....
    non+autenticato

  • - Scritto da: Anonimo
    > Finalmente qualcuno incomincia a pensare
    > anche alle povere vittime del Digital
    > Divide.
    >
    > Per me che navigo a 56k, navigare 6 volte
    > più veloce mi sembrerebbe un
    > miracolo! Ma funzionerà? Come si fa a
    > comprimere ulteriormente un JPG?
    >
    > Stiamo a vedere e speriamo.....

    quei numeri si riferiscono solo a compressioni su html, scordati vantaggi su download binari o su jpeg

    la banda te la può dare soltanto la centrale telecom, non certo opera
    non+autenticato



  • > la banda te la può dare soltanto la
    > centrale telecom, non certo opera

    si è vero ma questo algoritmo di compressione totalmente riscritto anche se con valori minimi comprimerà anche binari e jpg con un incremento non indifferente infondo se dovevano indicare la sola compressione del testo quella avviene al 90% quindi avrebbero scritto molto più di 6x anche io sono scettico sul 6x ma anche se fosse un 3x effettivo sarebbe una bella cosa!
    non+autenticato


  • - Scritto da: Anonimo
    > Finalmente qualcuno incomincia a pensare
    > anche alle povere vittime del Digital
    > Divide.
    >
    > Per me che navigo a 56k, navigare 6 volte
    > più veloce mi sembrerebbe un
    > miracolo! Ma funzionerà? Come si fa a
    > comprimere ulteriormente un JPG?

    hai detto giusto e la risposta è...non si fa o cmq molto poco quel valore è dato su di una media tra testo immagini audio ecc ecc ed è cmq un valore molto largo di manica è chiaro che un miglioramente sicuramente c'è e per tutti quei posti non ragiungibili dallìadsl è sicuramente una svolta.
    non+autenticato
  • Quoto dall'articolo:
    Perché ciò avvenga, sia il client (in questo caso Opera) sia il server (quello che fornisce il servizio di connettività all'utente) devono supportare la tecnologia di SlipStream: al momento nessun provider italiano ne ha ancora annunciato pubblicamente il supporto.

    ... te pareva che una volta tanto l'italia si distinguesse per essere quella più all'avanguardia... visto che siamo campioni nell'essere uno fra i paesi meno broadbandizzati d'europa almeno la banda stretta potrebbe essere migliorata!


  • - Scritto da: carobeppe
    > Quoto dall'articolo:
    > Perché ciò avvenga, sia il
    > client (in questo caso Opera) sia il server
    > (quello che fornisce il servizio di
    > connettività all'utente) devono
    > supportare la tecnologia di SlipStream: al
    > momento nessun provider italiano ne ha
    > ancora annunciato pubblicamente il supporto.
    >
    > ... te pareva che una volta tanto l'italia
    > si distinguesse per essere quella più
    > all'avanguardia... visto che siamo campioni
    > nell'essere uno fra i paesi meno
    > broadbandizzati d'europa almeno la banda
    > stretta potrebbe essere migliorata!


    Ma perchè parlate e non sapete? prima wind poi tin hanno annunciato il supporta a questa nuova tecnologia!!!
    non+autenticato
  • queste 2 forme di compressione sono gia' supportate sia da mozzilla che da IE... io mi chiedo xke i provider non abilitano la compressione di default, o perche' non venga richiesta (sempre di default) dai browser che la supportano.

    Risparmieremmo tutti un sacco di banda (appunto 6 volte in meno su html,asp,php etc...).
    non+autenticato
  • Perché i provider non le supportano? semplice... consuma CPU sul web server... ma anche se lo supportassero... gli utenti non se ne accorgerebbero!

    Questo è il mio sito:
    http://jack.logicalsystems.it/homepage/

    Secondo voi supporta le compressioni GZIP e/o Deflate?

    Si aprono scommesse...

    Mauro
  • > Secondo voi supporta le compressioni GZIP
    > e/o Deflate?

    NO
    se no sarebbe molto ma molto più lento.... la velocità sul web non nasce affatto dalla velocità di banda ma dalla velocità di risposta del server, ovvero, potenza di CPU, e qui GZIP e deflate fanno solo danni e nulla più.
    non+autenticato
  • > la velocità sul web non nasce affatto dalla velocità di banda ma dalla velocità di risposta del server, ovvero, potenza di CPU, e qui GZIP e deflate fanno solo danni e nulla più.

    azz.. un genio..
    non+autenticato
  • - Scritto da: Anonimo
    > > la velocità sul web non nasce
    > affatto dalla velocità di banda ma
    > dalla velocità di risposta del
    > server, ovvero, potenza di CPU, e qui GZIP e
    > deflate fanno solo danni e nulla più.
    >
    > azz.. un genio..

    Ed aggiungiamo che se si può salvare l'inventore del html con motivazioni storiche, altrettanto non si può fare con w3c per l'xml. Un grande passo avanti è indubbio: ma perchè utilizzare un linguaggio di markup che costringe a riscrivere il nome di un tag per chiuderlo? L'xml si poteva creare facendogli "consumare" quasi metà della banda. Inoltre a chi frega se con xml si può scrivere l'html? Non è forse vero che XHTML NON E' per nulla compatibile con HTML? Ah, ok sono le pagine scritte fino ad ora ad essere scritte maleOcchiolino
    Alle volte non li capisco...Triste

    ==================================
    Modificato dall'autore il 08/11/2004 7.57.50

  • > Ed aggiungiamo che se si può salvare
    > l'inventore del html con motivazioni
    > storiche, altrettanto non si può fare
    > con w3c per l'xml. Un grande passo avanti
    > è indubbio: ma perchè
    > utilizzare un linguaggio di markup che
    > costringe a riscrivere il nome di un tag per
    > chiuderlo?

    perche' cosi' il documento e' ben-formato e puo' essere processato da una macchina (cerca online i concetti di well-formed e machine-readable)

    > L'xml si poteva creare facendogli
    > "consumare" quasi metà della banda.
    > Inoltre a chi frega se con xml si può
    > scrivere l'html?

    A nessuno, infatti non e' nato per la visualizzazione ma per l'interscambio dei dati tra diverse applicazioni

    > Non è forse vero che
    > XHTML NON E' per nulla compatibile con HTML?

    No, basta che l'HTML sia scritto bene e diventa XHTML

    > Ah, ok sono le pagine scritte fino ad ora ad
    > essere scritte maleOcchiolino

    Esatto

    > Alle volte non li capisco...Triste

    Infatti, e' meglio se lasci stare...


    E comunque l'XML puo' utilizzare anche trasferimenti binary, certo qche meccanismo tipo gzip forse proprio male non fa...

    PS Per quello che dice che il gzip non serve niente, prova a caricare questo http://packages.debian.org/testing/allpackages
    e invece questo
    http://packages.debian.org/testing/allpackages.en....
    (ok che la prima e' html e la seconda txt, ma le velocita' non son neanche paragonabili...)


    Ecio
    non+autenticato

  • - Scritto da: Anonimo
    >
    ....
    > PS Per quello che dice che il gzip non serve
    > niente, prova a caricare questo
    > packages.debian.org/testing/allpackages
    > e invece questo
    > packages.debian.org/testing/allpackages.en.tx

    Presumo che intendesse nel caso di compressione 'on the fly' e non nel caso di un documento archiviato sul server in due versioni: compressa e non compressa. A questo punto bisogna vedere se è più veloce l'ISP a comprimere il pacchetto o la tua linea a trasferire il pacchetto non compresso. Ovviamente dipende tutto dalla velocità del server e, soprattutto, dalla velocità di collegamento. Chiaro che se sei collegato con una linea a 10 Mbps probabilmente farai prima a scaricare il pacchetto non compresso, mentre se ti colleghi con una velocità molto minore il discorso sarà diverso. Infatti Opera dichiara: "Su stessa ammissione di Opera Software, gli utenti di connessioni a larga banda (xDSL, cavo, satellite, ecc.) beneficeranno poco o nulla della tecnologia di SlipStream: dove questa può fare davvero la differenza, infatti, è sulle connessioni più lente, come quelle analogiche a 56 Kbps o quelle fornite oggi dalle reti cellulari (GSM, GPRS, EDGE, UMTS)."

    Una cosa però non mi torna... nel caso in cui la tecnologia potrebbe essere più utile, e cioè il collegamento tramite modem, mi risulta che la compressione dei dati si faccia ormai da anni e tra l'altro che venga effettuata via hardware dal modem, senza pesare quindi sul server.
    non+autenticato

  • > Presumo che intendesse nel caso di
    > compressione 'on the fly' e non nel caso di
    > un documento archiviato sul server in due
    > versioni: compressa e non compressa. A
    > questo punto bisogna vedere se è
    > più veloce l'ISP a comprimere il
    > pacchetto o la tua linea a trasferire il
    > pacchetto non compresso.

    Si questo e' vero, in caso di compressione on the fly i web server sarebbero caricati non poco. Ma l'idea di fare pagine gzippate non mi pare malaccio: con dei webserver abbastanza intelligenti la compressione potrebbe essere realizzata in anticipo sulle pagine statiche e invece in modalita' batch (oppure on demand + caching, tipo proxy) sulle pagine dinamiche



    > . Infatti Opera dichiara:
    > "Su stessa ammissione di Opera Software, gli
    > utenti di connessioni a larga banda (xDSL,
    > cavo, satellite, ecc.) beneficeranno poco o
    > nulla della tecnologia di SlipStream: dove
    > questa può fare davvero la
    > differenza, infatti, è sulle
    > connessioni più lente,
    > Una cosa però non mi torna... nel
    > caso in cui la tecnologia potrebbe essere
    > più utile, e cioè il
    > collegamento tramite modem, mi risulta che
    > la compressione dei dati si faccia ormai da
    > anni e tra l'altro che venga effettuata via
    > hardware dal modem, senza pesare quindi sul
    > server.

    Concordo con te, mi pare un po' una banfata quella della tecnologia + rivoluzionaria degli ultimi 20 anni...

    Ecio
    non+autenticato
  • > PS Per quello che dice che il gzip non serve
    > niente, prova a caricare questo
    > packages.debian.org/testing/allpackages
    > e invece questo
    > packages.debian.org/testing/allpackages.en.tx
    > (ok che la prima e' html e la seconda txt,
    > ma le velocita' non son neanche
    > paragonabili...)

    ma chi ha mai detto che gzip come compressione in quanto tale non serve a niente, il fatto è che on the fly fa danni enormi, perché il problema spessissimo dei web server è il consumo di cpu... e li se abiliti gzip il sistema si paralizza
    non+autenticato
  • > è indubbio: ma perchè
    > utilizzare un linguaggio di markup che
    > costringe a riscrivere il nome di un tag per
    > chiuderlo?

    Falso, in XML puoi chiudere un tag anche in questo modo:
    <img />

    >L'xml si poteva creare facendogli
    > "consumare" quasi metà della banda.

    Se lavori con gli strumenti giusti riesci anche a creare file XHTML più compatti rispetto a HTML, rimuovendo tutti i caratteri tipo spazi multipli, tabulazioni e cr che vengono ignorati dal parser.

    > Non è forse vero che
    > XHTML NON E' per nulla compatibile con HTML?

    No, è il contrario.

    Ciao
  • Invece SI!

    e con gprs la differenza si vede!!!

    Mauro