Chrome 15 stabile e nella 17 HTTP pipelining

Chrome 15 stabile e nella 17 HTTP pipelining

Una nuova versione stabile di Google Chrome è disponibile per il download, mentre nella release 17 è atteso il supporto all'HTTP pipelining

di Fabio Boneschi pubblicata il , alle 08:44 nel canale Programmi
Google
 

Google rende disponibile una nuova versione stabile di Google Chrome giunto alla release 15. Dal punto di vista funzionale ci sono poche novità che si limitano a una ridisegnazione della pagina dedicata all'apertura di una nuova tab e a una più radicale separazione tra app installate e gli altri preferiti.

Sul fronte della sicurezza Google ha risolto una ventina di vulnerabilità, alcune delle quali anche di considerevole importanza. Il tutto è documentato a questa pagina mentre il download può essere avviato da questa pagina di Hwfiles.it

Con il rilascio di una nuova release stabile Google diffonde anche interessanti anticipazioni sulle future versioni di Chrome. In particolare, a partire da Chrome 17 sarà disponibile la funzionalità di HTTP pipelining che consiste nell'effettuare richieste multiple sulla stessa connessione HTTP e senza attendere la risposta del server. Questa innovazione, già disponibile in Opera, dovrebbe portare vantaggi nell'utilizzo di Chrome con connettività scadente offrendo migliori prestazioni.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione

10 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
andrea260727 Ottobre 2011, 09:30 #1
Ok aver risolto i bug, aggiunto funzionalità e migliorato la sicurezza..ma ormai fra i browser è una "gara" a chi arriva alla versione con il numero più grande.

Una volta usciva una versione che cambiava radicalmente il browser e da li in poi fino ad un altro radicale cambiamento si avevano le sub-versioni mentre ora di così radicale cosa cambia? Secondo me l'unica che rispetta ancora questa cosa è Microsoft con ie, ogni volta che si sente ie7, ie8, ie9 si parla di versioni ,oltre dal lato estetico, strutturate in modo completamente diverse eogni volta migliori, perchè ie9 è davvero un ottimo browser, e non sono assolutamente fan di Microsoft, anzi, sono un super-fedelissimo di firefox che però in questo ultimo anno ha cambiato versione di continuo, secondo me peggiorando!!

Ormai per Mozilla e Google è una gara a dire: "io sono alla versione 7, io invece alla 15" quando invece si dovrebbe guardare allo sviluppo vero, visto che se andiamo avanti di questo passo ie10 sarà ancora meglio di chrome e firefox!
calabar27 Ottobre 2011, 09:54 #2
In realtà no, c'è una diversa filosofia di sviluppo dietro.
Si tratta mettere subito a disposizione i miglioramenti anziché aspettare una nuova release, lasciando nel frattempo il browser nell'obsolescenza rispetto ai concorrenti.
Ciò che è successo con FF 3.6 in attesa di FF4 insomma.

Quindi si è deciso di adottare la filosofia di sviluppo "alla chrome", che pareva più adatta ai tempi, e così abbiamo due browser che tirano di continuo fuori numeroni di versione.

Ma del resto sono solo numeri, per cui, dove sta il problema?
andrea260727 Ottobre 2011, 09:59 #3
Originariamente inviato da: calabar
In realtà no, c'è una diversa filosofia di sviluppo dietro.
Si tratta mettere subito a disposizione i miglioramenti anziché aspettare una nuova release, lasciando nel frattempo il browser nell'obsolescenza rispetto ai concorrenti.
Ciò che è successo con FF 3.6 in attesa di FF4 insomma.

Quindi si è deciso di adottare la filosofia di sviluppo "alla chrome", che pareva più adatta ai tempi, e così abbiamo due browser che tirano di continuo fuori numeroni di versione.

Ma del resto sono solo numeri, per cui, dove sta il problema?


Il problema non c'è perchè come detto uso firefox da sempre..però volevo solo far notare come ie ad ogni cambio di versione cambia radicalmente..mentre altri sparano numeri tutto l'anno ma poi rimangono quasi sempre li..la mia non è polemica sui numeri, anzi non è proprio polemica..è voler far notare che ie cresce davvero ad ogni versione..tutto qua!
Cimmo27 Ottobre 2011, 10:05 #4
Originariamente inviato da: andrea2607
Il problema non c'è perchè come detto uso firefox da sempre..però volevo solo far notare come ie ad ogni cambio di versione cambia radicalmente..mentre altri sparano numeri tutto l'anno ma poi rimangono quasi sempre li..la mia non è polemica sui numeri, anzi non è proprio polemica..è voler far notare che ie cresce davvero ad ogni versione..tutto qua!


Si chiama "agile development" o in italiano "metodologia agile" che come ha detto calabar giustamente tende a fare tante piccole release, piu' frequenti, ma con meno feature, in modo da non fare attendere 1 anno l'utente anche per la piu' stupida cosa che e' stata messa a posto solo nella release X, di fatto ha tanti difetti, ma ha anche i suoi vantaggi.
http://it.wikipedia.org/wiki/Metodologia_agile

Ad ogni modo bisogna che la gente si faccia una cultura e smetta di lamentarsi del numero delle versioni, perche' tutte le + grandi software house stanno andando in quella direzione.
Ora ad ogni notizia di Chrome o Firefox o dei driver nvidia (e' successo a suo tempo) c'e' sempre almeno un commento a riguardo.

Poi se Firefox e' diventato piu' instabile questo e' un altro paio di maniche, si vede che non hanno abbastanza QA.
speyer27 Ottobre 2011, 10:22 #5
Originariamente inviato da: Redazione di Hardware Upgrade
Questa innovazione, già disponibile in Opera


Mi risulta che sia da tempo disponibile anche in Firefox: è pieno di tutorial che spiegano come incrementare la velocità di Firefox agendo anche sui parametri di questa funzione (di default disabilitata)
II ARROWS27 Ottobre 2011, 12:16 #6
Cimmo, "Sviluppo Agile" non significa cambiare numero di versione per ogni minima cazzata che fai.
alibrandicus27 Ottobre 2011, 12:53 #7
Originariamente inviato da: Cimmo

Ad ogni modo bisogna che la gente si faccia una cultura e smetta di lamentarsi del numero delle versioni, perche' tutte le + grandi software house stanno andando in quella direzione.
Ora ad ogni notizia di Chrome o Firefox o dei driver nvidia (e' successo a suo tempo) c'e' sempre almeno un commento a riguardo.


Hai ragione, ma non c'è niente da fare, i commenti "intelligentissimi" riguardo il numero di versione ci saranno sempre...
E' triste perchè se uno nella vita si preoccupa del fatto che chrome si chiami 19 anzichè 10.18.310.250...allora...siam messi bene...
Mde7927 Ottobre 2011, 16:01 #8
Originariamente inviato da: alibrandicus
Hai ragione, ma non c'è niente da fare, i commenti "intelligentissimi" riguardo il numero di versione ci saranno sempre...
E' triste perchè se uno nella vita si preoccupa del fatto che chrome si chiami 19 anzichè 10.18.310.250...allora...siam messi bene...


I commenti "intelligentissimi" sono i vostri.
Chi ci deve sviluppare le applicazioni deve dare supporto a decine di versioni diverse ed è costretto a non supportare ufficialmente Chrome.
Firefox in parte è tornato sui suoi passi con il long term support.
Con i costi sempre tagliati al minimo si finisce per supportare solo Internet Explorer
jappilas27 Ottobre 2011, 19:27 #9
Originariamente inviato da: Cimmo
Si chiama "agile development" o in italiano "metodologia agile"

NO, non si chiama "agile development"
nello sviluppo sw le metodologie agili prevedono che il processo di: analisi dei requisiti -> design -> sviluppo -> testing e validazione -> feedback non sia più eseguito in una successione monolitica a livello di intero progetto, ma ripetuto iterativamente in cicli dallo scope ridotto, di modo da permettere al progetto stesso di sostenere variazioni nei requisiti (e di riflesso a livello di feature, interfaccia od anche di design architetturale) in corso d' opera
quindi minimizzare i fattori di rischio del processo di sviluppo - processo che per creare qualcosa che soddisfi sia le specifiche iniziali più quelle emerse nel tempo (soluzione completa da fornire alla clientela/ utenza, aka deliverable), richiederà comunque dei mesi o degli anni...
in questo non c'è molta differenza con le metodologie non agili (che anzi con un' accurata pianificazione iniziale possono a seconda dei casi perfino richiedere meno risorse - scendere nel dettaglio di cicli -> stories -> singoli tasks e gestirli individualmente crea un certo overhead), a parte il fatto che se lo sviluppo dovesse per qualsivoglia motivo interrompersi a metà, esiste comunque "qualcosa" (l' ultimo snapshot della code base) da far uscire...
MA, il prodotto del singolo task o della singola iterazione è sostanzialmente una release interna al team di sviluppo - che sia da equiparare a una deliverable non è scritto da nessuna parte, semmai è un' idea indotta dall' open source (che in questo senso è pericoloso perchè rischia di creare dei falsi preconcetti che poi si pretende di applicare al sw in generale) nella sua veste di modalità di distribuzione e deployment (visto che ogni build è anche una relase pubblica)...
Ad ogni modo bisogna che la gente si faccia una cultura e smetta di lamentarsi del numero delle versioni, perche' tutte le + grandi software house stanno andando in quella direzione.
così come non è scritto da nessuna parte che il sw debba uscire con nuove relase a scadenze regolari (3 mesi piuttosto che 6, 12 o..) piuttosto che "quando è pronto" come si è sempre usato...
o che debba essere numerato secondo criteri diversi da major_version.minor_version, dove un incremento di major_version è per convenzione sinonimo di novità sostanziali a livello architetturale e/o (anche solo) di interfaccia
esempio classico : il sw di animazione e modellazione Real3D già dalle prime versioni implementava le proprietà fisiche degli oggetti e li rappresentava nativamente in forma di nurbs, ma aveva un menu che definire ostico è riduttivo, e parecchie idiosincrasie... la gui venne completamente rifatta, il feature set e i menu non solo ampliati ma ortogonalizzati in ottica objet oriented (quindi chiara per l'utente), lo stesso core venne riprogettato di modo che ogni property potesse influenzare programmaticamente ogni altra, oltre a essere animabile, o che mesh nurbs, sds o poligonali potessero essere composte in modo seamless nello stesso oggetto
la nuova versione fu rilasciata come "realsoft version 4", cosa giustificata da tutto il lavoro che vi confluì - ed anche l' utente sapeva di potersi aspettare praticamente un programma del tutto nuovo (cosa che in effetti era)

ora, per Google Chrome non avviene nulla del genere, tra una relase e l' altra l' interfaccia è sempre la stessa, l' architettura a process separated tabs è sostanzialmente sempre la stessa, le funzionalità sono sempre le stesse, di browser (peraltro la tipologia di applicazione fruitiva più basilare e semplice dal punto di vista dell' utente, nonchè l' applicazione orizzontale per definizione) streamlined, con innovazioni che nella convenzione di cui sopra meriterebbero incrementi del major version number in uno o al più due occasioni ... motivo per cui Google sceglie bellamente di ignorarla, per dare all' utenza un' immagine di maggiore dinamismo (e peraltro convincerla che vada abolita in quanto anacronistica e superata)

quindi sì, occorre che la gente si faccia una cultura, ma non tanto per smettere di lamentarsi del numero delle versioni, ma per capire cosa è versioning e cosa è marketing...
maumau13827 Ottobre 2011, 19:35 #10
Originariamente inviato da: jappilas

NO, non si chiama "agile development"
nello sviluppo sw le metodologie agili prevedono che il processo di: analisi dei requisiti -> design -> sviluppo -> testing e validazione -> feedback non sia più venga eseguito in una successione monolitica a livello di intero progetto, ma ripetuto iterativamente in cicli dallo scope ridotto, di modo da permettere al progetto stesso di sostenere variazioni nei requisiti (e di riflesso a livello di feature, interfaccia od anche di design architetturale) in corso d' opera
quindi minimizzare i fattori di rischio del processo di sviluppo - processo che per creare qualcosa che soddisfi sia le specifiche iniziali più quelle emerse nel tempo (soluzione completa da fornire alla clientela/ utenza, aka deliverable), richiederà comunque dei mesi o degli anni...
in questo non c'è molta differenza con le metodologie non agili (che anzi con un' accurata pianificazione iniziale possono a seconda dei casi perfino richiedere meno risorse - scendere nel dettaglio di cicli -> stories -> singoli tasks e gestirli individualmente crea un certo overhead), a parte il fatto che se lo sviluppo dovesse per qualsivoglia motivo interrompersi a metà, esiste comunque "qualcosa" (l' ultimo snapshot della code base) da far uscire...
MA, il prodotto del singolo task o della singola iterazione è sostanzialmente una release interna al team di sviluppo - che sia da equiparare a una deliverable non è scritto da nessuna parte, semmai è un' idea indotta dall' open source (che in questo senso è pericoloso perchè rischia di creare dei falsi preconcetti che poi si pretende di applicare al sw in generale) nella sua veste di modalità di distribuzione e deployment (visto che ogni build è anche una relase pubblica)...
così come non è scritto da nessuna parte che il sw debba uscire con nuove relase a scadenze regolari (3 mesi piuttosto che 6, 12 o..) piuttosto che "quando è pronto" come si è sempre usato...
o che debba essere numerato secondo criteri diversi da major_version.minor_version, dove un incremento di major_version è per convenzione sinonimo di novità sostanziali a livello architetturale e/o (anche solo) di interfaccia
esempio classico : il sw di animazione e modellazione Real3D già dalle prime versioni implementava le proprietà fisiche degli oggetti e li rappresentava nativamente in forma di nurbs, ma aveva un menu che definire ostico è riduttivo, e parecchie idiosincrasie... la gui venne completamente rifatta, il feature set e i menu non solo ampliati ma ortogonalizzati in ottica objet oriented (quindi chiara per l'utente), lo stesso core venne riprogettato di modo che ogni property potesse influenzare programmaticamente ogni altra, oltre a essere animabile
la nuova versione fu rilasciata come "realsoft version 4", cosa giustificata da tutto il lavoro che vi confluì - ed anche l' utente sapeva di potersi aspettare praticamente un programma del tutto nuovo (cosa che in effetti era)

ora, per Google Chrome non avviene nulla del genere, tra una relase e l' altra l' interfaccia è sempre la stessa, l' architettura a process separated tabs è sostanzialmente sempre la stessa, le funzionalità sono sempre le stesse, di browser (peraltro la tipologia di applicazione fruitiva più basilare e semplice dal punto di vista dell' utente, nonchè l' applicazione orizzontale per definizione) streamlined, con innovazioni che nella convenzione di cui sopra meriterebbero incrementi del major version number in uno o al più due occasioni ... motivo per cui Google sceglie bellamente di ignorarla, per dare all' utenza un' immagine di maggiore dinamismo (e peraltro convincerla che vada abolita in quanto anacronistica e superata)

quindi sì, occorre che la gente si faccia una cultura, ma non tanto per smettere di lamentarsi del numero delle versioni, ma per capire cosa è versioning e cosa è marketing...


*

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^