Newsgroup: it.comp.lang.javascript
Titolo: xmlhttprequest in ordine FIFO

In presenza di ritardi nella comunicazione o di carico del server e' 
ovviamente possibile che le richiesta prodotte dall'oggetto xmlhttprequest, 
non vengano gestitre in ordine FIFO. La cosa puo' essere inacettabile in 
alcune situazioni.
Mi date qualche suggerimento in merito?
Poi non sono sicuro di una cosa: se faccio 2 richieste parallele con 2 
oggetti diversi siamo sicuri che ogni oggetto processa la risposta che gli 
compete? 

 alcune situazioni.
perché non lavori in modalità sincrona?
-- 
"Affacciati affacciati benedici, guardaci
 guardaci...guardaci!
 Tanto sono quasi duemila anni che stai a guardare!"
									    E.B.


Beh in generale mi sembra troppo pesante. Ad esempio se ho un timer che fa 
richieste e in piu' ci aggiungo quello dell'utente vien fuori che non si 
puo' far mai niente sulla finestra ;) 

 compete?
Sicura è solo la morte :)
Cmq, non basta fare un po' di prove per vedere come va?
-- 
Nando [?]
Apostolo della Prova

 Sicura è solo la morte :)
Conosco gente che discuterebbe anche su questo :) Per quanto mi riguarda, il
mio punto di vista è riassunto nella seguente frase:
	"Non esistono certezze, solo ragionevoli probabilità."
-- 
Quando hai la sensazione di essere osservato, ti sta guardando Chuck Norris.

 	"Non esistono certezze, solo ragionevoli probabilità."
In realtà sono assolutamente d'accordo con quest'ultima. Stavo solo citando
un proverbio napoletano (italianizzandolo, ovviamente) senza intenti
filosofici :)



Anche io la penso cosi', ma quando provo a spiegare a qualcuno che la morte 
non e' un evento necessario e quindi certo in senso assoluto si mettono a 
ridere! 

 ridere!
Quanto mi piacciono le disquisizioni ultraOT in 'sto periodo :))
Ah rega', potremmo pure discutere sul significato della morte o sulla sua
funzione, ma sul suo avvenimento, dubbio ne ve n'è alcuno. Sono poco
filosofico?
-- 
Ro!

 filosofico?
Beh... no! Però prima di ogni discussione bisogna porsi questa domanda:
cos'è la morte?
Ma è meglio di no, per me: oggi piove a dirotto e quindi non sono
dell'umore giusto :)


 senza intenti filosofici :)
Non fraintendermi, neppure il mio voleva avere intenti filosofici. La prima
frase era del tutto distaccata dalla seconda. Quando ho detto "Conoscono gente
che..", con smile a seguito, volevo solamente ironizzare sul detto in
questione; mentre quando ho scritto "Per quanto mi riguarda" parlavo
essenzialmente del mio punto di vista generale sulle "certezze e sicurezze",
in special modo in ambito informatico.
Quella che ho scritto, fa parte di quella stretta cerchia di frasi che ho
"fatto mie"; che ben si sposano a mio avviso con la programmazione.
Se mai un giorno scriverò un libro, un saggio, o qualsivoglia altra cosa
inerente il mio lavoro, penso che le elencherò tutte lì. Magari all'inizio di
ogni capitolo.
Non era mio intento iniziare un "OT", né tantomeno un OT filosofico, dal quale
mi guardo bene dal partecipare. :)
-- 
Chuck Norris è in grado di scalare le montagne in bicicletta. Su una ruota
sola. Senza mani.

 dell'umore giusto :)
Peccato, a Milano c'è un bel sole (il che di per sè è già un evento).
-- 
Ro!

 mi guardo bene dal partecipare. :)
Anche perché sulla filosofia non ho mai visto una persona ammettere di
avere torto, figurati quanto potrebbe durare una discussione simile ;)
-- 
Ro!


Il fatto che finora siano morti tutti quelli che sono nati ti fa concludere 
che la probabilita' di morire e' altissima, ma non certa.
Poi insisto sulla non necessita' della morta..non e' un evento necessario in 
senso matematico. Ad esempio non c'e' nessun risultato che afferma che un 
essere umano non possa arrivare a 300 anni, a 600 anni , a 1000 anni, 
all'infinito.
P.S
ma a me interessava di piu' l'ordinamento FIFO   ;) 

 avere torto, 
La filosofia non la vedo da un punto di vista di torto o ragione; partiremmo
già da due punti di vista diametralmente opposti.
-- 
Chuck Norris può dividere per zero.

 compete?
A meno di bug strani, si. Tant'è che anche utilizzando un singolo oggetto, la
chiamata al metodo open resetta tutta una serie di parametri.
Se ne è già discusso in un altro thread: quando associ un event listener a
"onreadystatechange", dopo il metodo "open" e prima del metodo "send", quello
viene "legato" alla richiesta in questione.
-- 
All'inizio dei tempi c'era il nulla. Poi arrivò Chuck Norris, colpì con un
calcio rotante il nulla e gli disse "muovi il culo!". Questa è la storia
dell'universo.

 già da due punti di vista diametralmente opposti.
In effetti torto non era la parola più adatta, ma è la prima che mi è
venuta in mente e forse maggiormente si avvicinava a ciò che intendevo.
Comunque ho fatto studi ben più pragmatici e i diversi punti di vista della
filosofia non sono mai stati il mio forte.
-- 
Ro!

 completata per eseguire la successiva richiesta.
Aspetto che sia completata significa che aspetta lui automaticamente o devo 
gestire la cosa?
Ho provato ma se faccio 2 richieste consecutive (mandando il sleep il thread 
sul server per 3 secondi ogni volta), si solleva un'eccezione  (sembra che 
il responseXML sia scorretto).
Se cosi' a che punto viene bloccato? in open, in send?
Ogni volta che l'utente lancia una richiesta si esegue anche questo codice:
 this.req.open("POST", data.url, true);
 this.req.setRequestHeader('Content-Type','application/x-www-form-urlencoded'); this.req.onreadystatechange = requestHandler(this, data); this.req.send(data.query);

 il responseXML sia scorretto).
Infatti ti ho anche detto "notare le virgolette".
-- 
In una rara scena tagliata de "L'Impero colpisce ancora", Chuck Norris rivela
a Darth Vader di essere suo padre.


E' bacato su alcuni browser mi sembra di capire.
Comunque leggendo su internet, sconsigliano di usare un unico oggetto, 
consigliano invece di fare richieste con un nuovo XmlHttpRequest.
Ho anche trovato un estensione dell'oggetto (
http://www.ajaxtoolbox.com/
) 
che dovrebbe fare le richieste nell'ordine che volevo, provero' a vedere 
come lo implementa.
Grazie. 

 consigliano invece di fare richieste con un nuovo XmlHttpRequest.
Se devi fare richieste parallele, ovvio. Rileggiti il mio reply iniziale in 
merito.
Se invece le richieste sono serializzate (non sincrone, ma serializzate) il 
discorso è diverso.
Dipende tutto dal contesto applicativo.
-- 
Chuck Norris ha inventato la puntualità, spaccando il secondo. Con un calcio 
rotante.


L'applicazione puo' prevedere anche  un timer che fa richieste costantemente 
ogni tot secondi, e in piu' l'utente che preme un link che "fa uso" di 
XmlHttpRequest. Quindi possono capitare richieste parallele.
Comunque potrei anche in questo caso usare sempre lo stesso oggetto per il 
timer, e un altro oggetto per l'utente. Insomma un approccio misto forse 
sarebbe la cosa migliori.
Ma per curiosita' e non solo...come fai/fate a serializzarle usando lo 
stesso oggetto?

 stesso oggetto?
Ci sono diversi modi, ma dipende sempre dal contesto.
Sempre in riferimento al thread sopracitato, Nando ad esempio ha fatto si di
far partire la schedulazione di una nuova richiesta nell'onreadystatechange
della precedente, quando il readyState raggiunge il valore 4 (completed). In
modo da evitare che si vadano a sovrapporre.
Ma in merito a questo, è bene che tu senta direttamente lui (Sacra Tecnica
dello Scaricabarile della scuola Saotome)
-- 
Chuck Norris ha giocato alla roulette russa con una pistola completamente
carica e ha vinto.

 dello Scaricabarile della scuola Saotome)
Ecchime! Posso portare solo la minuscola esperienza di un aspirante
programmatore che, con un po' di aiuto, ha trovato *un* modo che appare
efficace ed efficiente per risolvere un problema.
Per cicap (se interessa)... l'approccio č molto semplice, e te l'ha
spiegato nella sua essenza zer0; in piů, c'č l'utilizzo di una sorta di
"buffer" per i messaggi in uscita: quando l'utente clicka su "Invia" per
mandare il proprio messaggio alla chat, non viene fatta partire alcuna
richiesta ma semplicemente il testo del messaggio viene accodato al buffer;
l'unico oggetto che gestisce le richieste asincrone preleva, ogni volta che
deve essere inviata una richiesta, il contenuto del buffer (se non č vuoto,
ovviamente) e lo invia. I dati che ritornano dal server sono sempre gli
stessi (i nuovi messaggi della chat) in ogni caso.
Riguardo al mio primo post in questo thread... davo per scontato che
l'esigenza di cicap fosse quella di gestire l'invio di richieste parallele,
da cui l'esigenza di serializzarle in qualche modo. Oddio... in effetti i
concetti di "parallelo" e "seriale" appaiono un po' antitetici :)



Grazie!
Penso che prendero' spunto dalla tua idea...anzi diciamo che te la copio del 
tutto!
Se trovo problemi nell'implementazione rompero' anche a te... ;) 

 Se trovo problemi nell'implementazione rompero' anche a te... ;)
Quassì cosa, a esposizione.


 tutto!
Se ti puň essere d'aiuto, questo č il thread relativo:
http://groups.google.it/group/it.comp.lang.javascript/browse_frm/thread/c65b0ec0ccacd626/
-- 
Chuck Norris non porta l'orologio. Decide lui che ora č.


Ecco il primo:
-buffer e' un array e serve per accodare le richieste
-performRequest fa open e send di XmlHttpRequest
RequestManager.prototype.go = function (data) {
    if(this.buffer.length == 0) {
      this.performRequest(data);
    }
    this.buffer.push(data);
}
C'e' un problema di sincronizzazione secondo me.
E' possibile che 2 chiamate parallele al metodo go entrino entrambe nel 
"if". La funzione dovrebbe essere atomica, ma JS non da la possibilita' di 
sincronizzare vero? 

 sincronizzare vero?
Allora... mentre go() è in esecuzione, credo proprio che non possa essere
invocata nuovamente. Ma credo che tu ti riferisca al fatto che si può
verificare quanto segue:
- il buffer è vuoto
- viene invocata go(); essendo il buffer vuoto, viene invocata
performRequest() e parte una richiesta asincrona
- go() esce, il buffer è sempre vuoto
- viene invocata nuovamente go(); essendo il buffer vuoto, viene invocata
performRequest() e parte una richiesta asincrona
A questo punto, se la precedente richiesta non era stata completata,
succede un casino. Se usi un solo oggetto XmlHttpRequest, il problema, come
già detto, è assicurarsi che una nuova richiesta possa partirte *solo* se
la precedente è stata completata.
Se, come in una chat, le richieste devono essere inviate di continuo, una
dietro l'altra, un metodo può essere, come ha già detto zer0, quello di far
partire una nuova richiesta ogni volta che la precedente è stata completata
inserendo la chiamata a performRequest() all'interno del gestore
dell'onreadystatechange.



No intendevo questo:
C'e' un timer che parte e fa richieste ogni tot. C'e' un utente che puo' 
scatenare una reichiesta.
1)Il timer parte entra in go e passa il test (perche' all'inizio il buffer 
e' vuoto).
2)Prima che possa aggiungersi al buffer, l'evento dell'utente entra in go e 
fa ache esso il test del buffer vuoto.
A questso punto entrambi hanno successo, quindi ho 2 richieste parallele.

 ha scritto:

Prima che "cosa" possa aggiungersi al buffer? Boh... insisto che, secondo
me, conviene seguire l'approccio suggerito da zer0 e che ho usato per la
mia chat. La cosa consiste nel /non usare setInterval/ per schedulare le
richieste, ma usare un setTimeout per schedulare la prossima richiesta, e
il setTimeout va inserito nel gestore dell'onreadystatechange e va lanciato
solo quando readyState==4 (richiesta completata): in questo modo sei
*certo* che una richiesta parta solo se quella precedente è stata
completata.
Ho messo su una pagina di prova, se ti va di dare un occhio; l'essenziale è
nel file .js esterno.
http://tinyurl.com/mjbso
