ajax returdata læses direkte

<ole>

Du kan ikke lave en konstant åben forbindelse over HTTP uden lynhurtigt at slide serveren i knæ. Brugen af sleep-funktionen i PHP er i denne forbindelse en _rigtig_ dårlig idé. En chat-applikation, bygget på den teknik, kan kun bære ganske få simultane brugere og bruges derfor aldrig i halv- eller helseriøse projekter.

Derudover skal du vente, til klienten melder, at readyState er 4, før du kan bruge de modtagne data. En readyState på 3 betyder, at klienten er igang med at modtage data - 4 betyder, at klienten har loaded alle data og at disse er klar til brug.

At FF kan bruge data, når den påstår, at readyState er 3, beror på en af FF's utallige fejl. Hverken response headers eller status er færdige på det tidspunkt ... er de det, bør browseren melde, at readyState er 4.

Jeg tror, du bør sætte dig lidt mere ind i XMLHttpRequests - herunder readyState-property'en - og PHP's sleep-funktion og hvilken katastrofal effekt, den har på serverens performance, når den bliver brugt forkert (f.eks. til en chat-applikation)  ;o)

/mvh
</bole>

Nu skal du ikke undervurdere mig :) sleep blev blot nævnt for at illustrere min pointe på en simpel måde. Faktisk ønskede jeg at benytte mig af stream_socket_server() i php til at "servicere" brugerne i f.eks. en chat. På den måde ville ét script, og kun en session af dette script, håndtere flere hundrede brugere. Scriptet ville kun (hvis overhovedet) have én database forbindelse åben, og efter min vurdering ville denne metode derfor være MANGE gange mindre ressourcekrævende og mange gange hurtigere end den gamle loop-refresh metode.

Det er jo netop den fordel som flash og java har (socket forbindelser), så det irriterer mig grænseløst, at MS åbenbart har valgt at afskære os fra en så revolutionerende mulighed.

Undskyld, men jeg undervurderede dig ikke. Måske tværtimod, idet jeg forudsatte, du skrev, hvad du mente: "sleep(x)"  ;o)

Dette er, hvad W3C skriver om readyState-property'ens værdier i deres arbejdspapir for XMLHttpRequest-objektet:

0 Uninitialized
    The initial value.
1 Open
    The open() method has been successfully called.
2 Sent
    The user agent successfully acknowledged the request.
3 Receiving
    Immediately before receiving the message body (if any). All HTTP headers have been received.
4 Loaded
    The data transfer has been completed.

Som du ser, er det ikke noget MS afskærer dig fra. At Mozilla har valgt at lave en proprietær implementering af objektet, er ikke rigtig noget, man kan bebrejde MS.
Derudover er XMLHttpRequest-objektet jo ikke tænkt som et 'streaming-objekt' - så det ville vel kun kunne undre, hvis det virkede generelt  :)

Fandt du ud af det?

Ja, og jeg troede også at jeg skrev et langt svar... utroligt at et netsted for udviklere ikke kan finde ud af at få styr på session-varighed, så man ikke mister de svar, som man bruger lang tid på :S

I mine noter står der følgende, hvilket var grund til min forvirring:

status 3 INTERACTIVE Downloading, responseText holds the partial data.

Jeg kan godt se at microsoft ikke kan holdes "ansvarlig", omend jeg stadig synes at det er en gylden mulighed, som vi js/php programmører går glip af.

Hehe ... ak ja, sessions og Eksperten  :oP

ResponseText er nok vore dages tabeller ... forstået på den måde, at ligesom man i 90'erne brugte tabeller til - på en helt forrykt måde - at konstruere layout-grids i form af dybt nestede tabeller, udspændt af transparent giffer, bruger man idag responseText til noget, den aldrig har været beregnet til.
Ikke mindst i de mange forskellige, 'kreative' Ajax-løsninger, der hærger nettet i disse tider, ses mange 'helt-hen-i-vejret' løsninger, byggende på responseText.

En XML-parser må kun forsøge at parse et validt dokument. Et validt XML-dokument er altid velformet. Det er det kun, hvis dokument-elementet er afsluttet - hvilket først kan afgøres, når klienten har modtaget en EOF-notifikation (End Of File).
Skulle parsingen gå galt, har man responseText'en til at teste, hvad der kom tilbage fra serveren - og evt. hvorfor resultatet ikke kunne parses.

Det har aldrig været meningen, at data skulle sendes i ikke-XML-formateret form - og aflæses med responseText. Det er en helt forkert fremgangsmåde, som ovenikøbet lægger op til adskillige, mulige fejl.

XMLHttpRequests har således aldrig været beregnet til streaming af data. Derfor er der heller ikke nogen, som 'går glip' af gyldne muligheder ... mulighederne i visse klienter består udelukkende i tilfældige fejl ved implementeringerne af teknologien  ;o)

God pointe. Men bare fordi en mulighed ikke har været planlagt fra starten, kan den stadig være god :)

Vil du have point for din tid i denne diskussion? Jeg går ikke op i pointene, så du skal være velkommen.

Nej, lad os vente til en anden gang  :)

Fair nok, lukker tråd.