Newsgroup: it.comp.macintosh
Titolo: Gmail e webkit

Scusate qualcuno sa quando webkit e gmail si metteranno d'accordo per
avere le chat?? a me safari e shiira piacciono e ogni tanto li provo,
ma davvero al chat è comoda!
In alternativa qualcuno ha un modo per spoofare elegantemente il
prorio browser in maniera che funzioni?
grazie

 avere le chat??
eh? io ho un acount jabber di gmail e lo uso in adium e in ichat
-- 
I've always been more concerned with users. )\._.,--....,'``.
Programmers do their work but once, while  /,   _.. \   _\  (`._._,
users are saddled with it ever thereafter. `_.-(,_..'--(,_..'`-.;.'

 eh? io ho un acount jabber di gmail e lo uso in adium e in ichat
lo so, ok ma a parte il fatto che ichat non abbia ancora imparato a
passare i proxy, c'è il fatto che non ho voglia di un'altra
applicazione a giro e gmail è ormai sempre aperta...
ho provato ora il webkit notturno dato che pareva che a qualcuno
spuffandosi (che bella parola mi sembro gargamella!) come firefox
funzionasse senza renderizzare molto bene, ma proprio non mi fa nulla.
per ora vado di camino. Di tanto in tanto proverò le versioni
notturne.
Se qualcuno si accorge che funziona, posti qualcosa qui (e così farò
io!)
ciao e 'notte

 webkit e gmail
La tecnica che usa Google per le chat fa girare il caricamento della
pagina all'infinito, che non si vede in Firefox ma in Safari sì.
Fa un po' schifo a vedersi.
-- 
 - ∞
-- 
http://infinite-labs.net

 
praticamente è un aggiornamento continuo..?
allora hanno ragione quelli della Apple....

 allora hanno ragione quelli della Apple....
Non capisco ma non è AJAX che gestisce la cosa?

 wrote:

È una tecnica che nel gergo del detersivo :) si chiama Comet.
In pratica una pagina che non finisce mai di caricare, nella quale
vengono generati tag <script> in momenti opportuni che il browser
interpreta immediatamente.
("Ajax" "liscio" fa una richiesta ogni tot, mentre con questa tecnica è
il server a inviare le cose al client una volta stabilita la
connessione, permettendo un controllo molto fine sui tempi come serve ad
es. nelle chat).


 es. nelle chat).
No no, non funziona cosi` e WebKit ha risolto il problema se non erro
visto che io con COMET ci lavoro tutti i giorni (ed e` l'unico modo di
fare IM con il browser, Ajax e` unammerda per motivi di scalabilita`
piu` che di tempi). Non vengono comunque generati tag <script>, non
funziona cosi` :). Pero` e` COMET si.
E WebKit ha da sempre avuto gravi gravi gravi gravi problemi con
javascript e google ne ha patchati parecchi. 
-- 
Valentino Volonghi aka Dialtone
Blog: 
http://www.twisted.it/
Wii Code: 3069 7621 2175 6539
Mario Strikers Code: 395238 578036

 funziona cosi` :). Pero` e` COMET si.
A no? Allora non ho proprio capito come funge (anche se a me pareva
che... boh. Mai fare assunti quando si parla di software, sigh >_<).



-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair


Uhm. Capisco, ma è esattamente quello che dicevo: un server mantiene una
connessione aperta su cui "spinge" eventi (in modo imprecisato, ma
meglio di uno <script>eventHandler('faiQualcosa');</script> inviato in
blocco non vedo quali ce ne siano :D).
Comunque grazie dell'articolo. (Ho guardato pure su Wikipedia e c'è una
marea di link, come qualsiasi cosa ci sia su Wikipedia >_<)


 fare IM con il browser,
e' una tecnica vecchia come il mondo, in ogni libro di PHP, Perl etc. si
trova un esempio di chat IRC che sfrutta questo trucco
-- 
"Un atteggiamento di disprezzo, di contestazione o di rigetto della
società, dell’istituto familiare, dell’ordinamento socio-politico,
o di sola ricerca del piacere" -- Ioannes Paulus II

 blocco non vedo quali ce ne siano :D).
Non ci sono i tag <script> il client si aspetta di ricevere qualcosa in
un formato che sia il client che il server conoscono. Sia esso JSON
(quasi sempre), XML, Javascript e quant'altro.
 
La connessione viene mantenuta aperta dal client che dopo ogni request
del server la riapre, il server di contro ha bisogno di mantenere vivo
l'oggetto che ha risposto alla request permettendo di tenere uno stato
della connessione ecc ecc. Solitamente i server sincroni non riescono a
implementare COMET e chi di loro lo implementa, sempre solitamente, lo
fa passando da un componente esterno come cometd (sviluppato da Alex
Russel). Quelli che invece usano server asincroni tipo Twisted Matrix
riescono a usare comet senza farsi troppi problemi, e` anzi piu`
semplice di AJAX e viene decisamente gratuitamente.
Nonostante sia chiamata XMLHttpRequest l'unica cosa che non ho mai visto
trasmetterci sopra e` XML :).


 trova un esempio di chat IRC che sfrutta questo trucco
La vedo molto molto dura. PHP non ha un server web asincrono che sia in
grado di supportare decentemente COMET. Puoi sempre fare polling in
continuazione portando in ginocchio apache o chi per lui oppure usando
un quantitativo di RAM da far impallidire i "Big Iron".
Pero` e` vero che e` vecchia come il cucco, noi la usiamo da molto prima
che lo facesse google ma ovviamente se lo facciamo noi non frega nulla a
nessuno, se lo fa google e` per forza di successo. 


 del server la riapre
È un po' un trade-off: una tecnica del genere "rischia" di andare in
timeout o peggio di perdere le finestre tra ricezione e riconnessione,
ma immagino sia meno pesante sul lato server e "liberi" periodicamente
la seconda connessione che i browser permettono alla pagina, consentendo
eg di caricare immagini.


 trova un esempio di chat IRC che sfrutta questo trucco
Vero. Il movimento "AJAX" più che altro ha dato a. nomi alle cose e b.
spinta ai browser maker perché uscissero dal momento stagnante
(*cough*IE*cough*) e aiutassero oltre che se stessi anche chi il web lo
voleva arricchire davvero.


 se lo fa google e` per forza di successo
Frase opinabile: altri l'han fatto _E_ non hanno avuto successo, Google
l'ha fatto _E_ ha avuto ampio successo, per cui non vedo perché non
dargliene atto.
È giusto ovviamente non prendere per oro colato tutto quel che fa
Google, ma cappero, certe cose le fanno bene. (Sto giocherellando con
Gears ultimamente, quello per Safari preso da SVN pare fungere molto
bene.) 


 bene.) 
se non sei Google (o qualunque altro big) e' difficile avere la visibilita'
per mostrare che sai fare bene, qualunque meraviglia tu abbia partorito.
Il discorso che le idee innovative hanno sempre successo e' vero fino ad un
certo punto.


 eg di caricare immagini.
La risposta e` si e no. Si e` vero che la pagina rischia di andare in
timeout e proprio perche` il problema e` frequente si e` fatto in modo
di porvi rimedio da subito. Se cade la connessione del server verrai
disconnesso, ma la connessione in se ha durata abbastanza breve e resta
in vita per un periodo di tempo massimo predefinito. Chiaro che se usi
un server COMET lo fai perche` _sai_ che la tua applicazione ha un
flusso dati molto grosso, in caso contrario COMET e` piu` di quello che
hai bisogno (anche se puoi comunque inviare dei nop ogni X secondi per
tenere vivo il tutto). Inoltre per renderlo piu` reliable si tende a
usare anche la seconda connessione si.
Lato server COMET e` immensamente meno pesante, posto un server che sia
in grado di gestirlo.


 bene.) 
... C'entra un tubo tutto cio`. Non solo google non ha inventato ne`
ajax ne` comet ma non e` stato neanche il primo a implementare roba
grossa. E` stato il primo a farlo e a diffonderlo molto, bella forza
pero`, era gia` l'azienda piu` grossa del web, qualsiasi cosa faccia
viene sparata in automatico ovunque. La capacita` di gestire una grossa
mole di utenti e` cio` che li contraddistingue maggiormente e cio` che
tengono davvero segreto.


 certo punto.
Assolutamente esatto.


 voleva arricchire davvero.
Teniamo a precisare che COMET _NON_ e` AJAX e non e` neanche un derivato
di AJAX. Il fatto che il secondo sia piu` famoso del primo non significa
_per nulla_ che sia nato prima, la realta` e` proprio l'opposto e
proprio perche` in PHP una cosa come COMET e` davvero complicata da
realizzare.
COMET esiste da MOLTO prima (e non per nulla gmail e` COMET e non Ajax).
Se volete potete considerare Ajax come una versione semplificata di
Comet per tutti quelli che non hanno ancora capito il vantaggio della
programmazione a eventi. E per COMET la tecnologia e` effettivamente
diversa, non e` la stessa (serve appunto un server a eventi dietro).


 voleva arricchire davvero.
spingere per l'adozione e l'implementazione degli standard suggeriti dal
W3C che non guasta mai, per contro generando tutta una babele di librerie
che in realta' sotto sotto svolgono le medesime operazioni.


 tengono davvero segreto.
unita a quanto pare (si vedano le domande delle interview-esami di google)
ad una maniacale ricerca di algoritmi ottimali (questo dovrebbe in realta'
essere la norma ovunque)


 tengono davvero segreto.
Ma neanche tanto, si sa più o meno bene come è strutturato un data
center di Google (un botto di blade x86 e hardware a qualità media, non
alta/specializzata, per contenere i costi) e ci sono diversi whitepaper
sulle tecniche che usano (ie MapReduce).
Arrivarci costa un botto, e loro vendendo pubblicità hanno preso un
botto di soldi e ci sono arrivati. Bon per loro. Non vuol dire che non
sia possibile fargli concorrenza!


 che in realta' sotto sotto svolgono le medesime operazioni.
La cosa buona di ciò è che ognuno può scegliere la sua e tanti saluti.
(Sono parziale verso jQuery, personalmente.)
Il web è lo sweet spot dell'interoperabilità. Dentro un'applicazione uno
fa come vuole, se vuole esporre i propri dati o i propri servizi poi lo
può fare usando un certo numero di standard de jure o de facto (eg XML,
JSON). HTTP fornisce un metodo semplice di arrivare a un dato. E fine.
Niente Feature Bloat™.


 di AJAX.
Volente o nolente è finito sul carrozzone insieme al resto della Roba
Che Siamo Riusciti A Cavare Fuori dal DHTML (d'ora innanzi RCSRACFD --
nuovo acronimo), e amen. Capisco e condivido l'intento filologico, ma è
poco interessante la tecnica in sé rispetto a quanto se ne può sfruttare
in congiunzione con altri accorgimenti.
(Che poi la tecnologia dietro evolva in modo migliore grazie ad essa è
un discorso separato -- fantastico, tra l'altro! non vedo l'ora che si
possa applicare al tag <event-source> di HTML5, tra dieci anni, quando
IE si sforzerà a supportarlo :D)
---
PS: 'sti acronimi mi fanno un pelo 'chifo, come speravo -- debolmente --
di far notare dalle virgolette nel post padre. L'unico che forse si
salva è RIA, perché descrive il fine e non il mezzo. Ma vabbe'.


 Anche JSON, quando presente, viene mandato come testo di un nodo.
Be', no, di solito si usa responseText. Meno casini. Tanto il parsing,
se non è fatto alla cavolo, fallisce subito (correttamente) mancando il
<?xml in prima posizione, e la performance non subisce danno.


 non è la scelta del medium, quanto dello strumento.
Non e` proprio questo il motivo.
Sito normale dinamico:
10.000 utenti fanno un numero X di request quasi sempre minore di
10.000, e molto spesso minore della meta`, ogni secondo.
Sito ajax:
10.000 utenti fanno polling ogni secondo perche` cosi` vuole la loro
libreria ajax, il sito si ritrova sommerso da 10.000 request ogni
secondo e ben presto viene messo in ginocchio perche` ogni request si
spara un thread separato.
Sito comet:
10.000 utenti navigano sul sito, fanno la loro request sulla pagina che
resta in idle finche` il server non ha dati e a quel punto si sveglia la
connessione. Dato che si implementa con server asincroni e primitive di
I/O che supportano gli eventi (kqueue, epoll e via dicendo), che sono
pure O(1) sul numero di socket, anche fossero 20.000 la ram occupata
sarebbe circa la stessa e nessun thread.
Il tutto parlando di singolo server. Per piu` server basta aumentare gli
utenti contemporanei, per determinati tipi di applicazioni (come gli IM)
bastano anche meno utenti per portare in ginocchio un server.


 sia possibile fargli concorrenza!
Su questo hai assolutamente ragione, e gli esempi si sprecano.  YouTube,
applicazione tutta in Python tra l'altro (Python non e` esattamente "il
segreto di Google", infatti anche Valentino lo conosce benissimo:-), a
suo tempo sconfisse sonoramente GoogleVideo (e senza neppure chissa` che
"botto di soldi"), infatti la comprammo, questo si`, per un botto e
sessantacinque:-).  Paypal continua a battere sonoramente Google
Checkout, e Meg Whitman, la CEO di EBay, se ne e` vantata anche molto di
recente.  Orkut e` popolare in Brasile e in India, ma in America e in
Europa sono assai piu` popolari altri siti sociali, come MySpace.  E gli
esempi si potrebbero moltiplicare per pagine e pagine.  Insomma, la Web
e` grande, gigantesca, il suo sviluppo e` *appena iniziato*, ed e`
possibilissimo far concorrenza a Google e vincere: se dai un servizio
migliore, come (a giudizio del mercato) YouTube era migliore di
GoogleVideo o (a giudizio degli americani del Nord:-) MySpace di Orkut,
i clienti "ci mettono un clic" a passare alla concorrenza.
Dal mio punto di vista, questo e` un fattore meraviglioso, estremamente
positivo e stimolante: proprio perche` la concorrenza e` possibilissima,
vivissima, ed estremamente evidente, non possiamo e non potremo mai
"riposarci sugli allori" -- dobbiamo e per sempre dovremo continuare a
"correre piu` in fretta per restare allo stesso posto", come la Regina
Rossa di Alice nel Paese delle Meraviglie -- fare del nostro meglio per
continuare a migliorare e tenere contenti i clienti.
Ho visto aziende piene di persone assolutamente brillanti ma che,
consciamente o meno, percepivano di godere di posizioni dominanti, di
avere "catturato" la clientela... e finire per "adagiarsi", operando ben
al di sotto del potenziale delle loro persone.  L'ho visto da dentro, in
IBM sul finire degli anni '80, e infatti me ne sono andato poco prima
del crollo, non perche` avessi doti di preveggenza e prevedessi il
crollo, ma perche` non e` quello della rilassata mediocrita` l'ambiente
in cui voglio spendere il mio tempo e le mie energie, mai.  Credo di
averlo notato "da fuori" in Microsoft (che non conosco di prima persona,
ma mi baso su amici che ci sono stati oltre che sulla marea di
informazioni pubblicate in merito).  Non so se Apple ci e` passata negli
anni '90 e se questa fu fra le cause della sua crisi, perche` all'epoca
non ne seguivo le vicende, ma non mi stupirei se cosi` fosse.  In
un'azienda dove e` clamorosamente ovvio che "il concorrente e` sempre a
un clic di distanza", SO di non dover temere questi sviluppi...!-)
Alex

 continuare a migliorare e tenere contenti i clienti.
I clienti ringraziano :) Alla fine ci si guadagna quasi tutti, come
innovazione, soddisfazione e livello di servizio, anche se immagino che
far quadrare i conti per un'azienda che voglia investire nel campo sia
dannatamente complicato.
