[AJAX?] web irc client zonder refresh

[Verwijderd]

hmja.. ik heb een php script gemaakt dat connect naar een irc server en dat werkt allemaal al heel aardig. probleem is dat dit een php script is in een loop, anders is je connectie immers gelijk weer weg. zorgt er natuurlijk helaas wel voor dat je alleen alles kunt lezen wat er gebeurt in een kanaal, maar iets terugzeggen gaat nog bijster lastig, en dat is natuurlijk wel een beetje een vereiste van een irc client

nu zag ik laatst op paiq (ajax datingsite) dat er nu en dan ineens iets begint te knipperen als je bijv een bericht hebt, ik gok dat ik ook zoiets zal moeten gebruiken, maar hoe ik dat in de praktijk fix is me nog duister.

nog even duidelijk wat ik wil:
- een socket naar irc die open blijft
- input regeltje die shizzle over de socket stuurt zonder refresh (dit moet wel mogelijk zijn met ajax)
- iets dat luistert naar binnenkomende zooi van de socket en het zonder refresh op het beeld plempt

(of is dit alles uberhaupt niet mogelijk zonder java applets en andere ongein?)

[Vinnienerd]

En je vraag is...?

[Ramon]

Je zou bijvoorbeeld de client kunnen laten interfacen met een database en dan in het scriptje wat verbinding maakt met de irc-server om de zoveel tijd checken of de client iets in de database heeft gezet en dit naar de irc server kunnen sturen.

Niet erg handig lijkt me maar is wel een optie.

[Verwijderd]

Je hebt sowieso een IRC client nodig die continu verbonden is met de server. Of dat tussen de webserver en de irc server is, of tussen de client en de irc server, doet er niet zoveel toe.

PHP is hier niet zo geschikt voor, je zou eerder aan bijvoorbeeld een Java servlet denken als het op de server moet draaien, of bijvoorbeeld een een Flash object of Java applet als het op de client moet draaien.

Bij een webserver die een connectie met de irc server houdt, kun je nog steeds (beter) niet iets naar de client pushen. De client kan dan beter elke zoveel tijd pollen, bijvoorbeeld via een XMLHttpRequest of via een (verborgen) (i)frame.

De client zelf verbinding laten maken met de server (eventueel via de webserver) is dan toch handiger.

[Johnny]

Hier twee real-life voorbeelden:
http://www.linuxuser.at/lachat/index.html
http://treehouse.ofb.net/chat/

[Verwijderd]

Meerdere mogelijkheden, pollen mbv xmlHttpRequest, of een HTTP connectie openhouden en steeds nieuwe informatie sturen die je dan kan behandelen (flush).

[ Voor 3% gewijzigd door Verwijderd op 11-03-2006 23:05 ]

[SchizoDuckie]

over de push/http connectie openhouden tip, dat hebben ze tegenwoordig ook een hip naampje gegeven: comet

[Verwijderd]

bedankt allemaal voor de reacties, ik ga het morgen in nuchtere staat eens goed lezen.

even dat comet gebeuren bekeken, en wat ik zo zie is het precies wat ik nodig heb:

As is illustrated above, Comet applications can deliver data to the client at any time, not only in response to user input. The data is delivered over a single, previously-opened connection. This approach reduces the latency for data delivery significantly.

immers, het probleem dat ik heb is dat er ook dingen moeten gebeuren zonder dat er user input is. ik check het allemaal morgen, jullie zijn nog niet van me af

[Verwijderd]

Dat is dus een open HTTP connectie.

[Verwijderd]

SchizoDuckie schreef op zondag 12 maart 2006 @ 02:32:
over de push/http connectie openhouden tip, dat hebben ze tegenwoordig ook een hip naampje gegeven: comet

waah heeft dat ook al een naam ik ken het zelf als snailhttp, maar da's volgens mij een indoor term

[Verwijderd]

Maar ik zie zelf niet echt nut van een open connectie. Pollen is snel genoeg, zeker voor chats, en een gemiddelde webserver trekt makkelijk honderden connecties simultaan. Moet je alleen serverside oplossingen gaan zoeken om data snel beschikbaar te maken, en in de juiste volgorde, dus static bestanden gaan wegschrijven die je dus snel kunt serveren of iets derg.

[Verwijderd]

als ik het goed begrijp gebruikt de comet techniek activex grappen (correct me if i'm wrong) en een constant loopend iframepje maar dat lijkt me niet echt een goed idee..

pollen betekent dat ik op de server constant een script moet draaien met een open connectie? dus dat de irc socket niet via de ircclient.php die de gebruiker draait wordt gedaan? dat is in mijn geval ook niet echt handig. zo heb ik het nu al; een irc client (botje) die de naam van de web user + zijn bericht op irc plempt.. maar dat is dus niet echt een web irc client

[ Voor 4% gewijzigd door Verwijderd op 14-03-2006 20:27 ]

[Verwijderd]

Wat is volgens jou dan een Web IRC client. Wat mis je aan het pollen van een webservice door clients om de laatste messages op te halen? Je mag behoorlijk wat pollen per seconde om een server druk te krijgen hoor.

Wil je de laatste verse groentes bij de Edah pushen ofzo?

[Verwijderd]

grapjas

het probleem met een 'tussenclient', zoals ik dat nu heb, is dat die

- altijd online moet zijn (ding wil wel eens disconnecten om vage redenen, en dan moet ik em weer handmatig aanslingeren via ssh) en
- niet de naam van de gebruiker heeft (dus ook niet een oprechte whois geeft etc)

en tis gewoon geen echte web irc client op die manier.. maar das meer een puristisch/neurotisch probleem

[Verwijderd]

Ik snap van beide punten niet het probleem.

- altijd online moet zijn (ding wil wel eens disconnecten om vage redenen, en dan moet ik em weer handmatig aanslingeren via ssh) en

Niet nodig als je gaat pollen, als de connectie een keer faalt pakt een volgende polling het wel weer op.

- niet de naam van de gebruiker heeft (dus ook niet een oprechte whois geeft etc)

Nu ben ik je echt kwijt, ..

[oh,when?]

Hier een AJAX (AFLAX) voorbeeld dat stiekem gebruikt maakt van Flash en niet polled

HTH

[Verwijderd]

flash wil ik niet hoor

gordijnstok volgens mij hebben wij het allebei over iets anders..
bedoel je iets met persistent sockets misschien? ontdek hier net dat dat met php kan (pfsockopen) en daar moet wel iets creatiefs mee te verzinnen zijn

[Verwijderd]

Verwijderd schreef op woensdag 15 maart 2006 @ 02:16:
flash wil ik niet hoor

gordijnstok volgens mij hebben wij het allebei over iets anders..
bedoel je iets met persistent sockets misschien? ontdek hier net dat dat met php kan (pfsockopen) en daar moet wel iets creatiefs mee te verzinnen zijn

Waarom wil je geen Flash? Vind het persoonlijk een mooie oplossing, en de kans dat iemand geen Flash heeft is praktisch nihil.

Sterker nog, als je gebruikt maakt van Flash XML Sockets heb je een persistent connectie en als voor de hobby een Flash Communication Server te duur is, kun je met een simpele timer en een tcp/ip connectie in een eigen gebouwd programma heel ver komen. Ik heb in het verleden op dezelfde manier voor een raadszaal het conferencing systeem nog op het web moeten krijgen, en dat werkte prima.

[Verwijderd]

Verwijderd schreef op dinsdag 14 maart 2006 @ 20:26:
als ik het goed begrijp gebruikt de comet techniek activex grappen (correct me if i'm wrong) en een constant loopend iframepje maar dat lijkt me niet echt een goed idee..

nee, wel met activex (lees: xmlhttp) of een iframe, maar niet refreshend. Wat je eigenlijk doet is een retetrage server simuleren (vandaar snailhttp), die maar mondjesmaat je data doorgeeft. Je hoeft dan niet te refreshen, maar je leest tijdens dat laden (wat dus een hele tijd kan duren) steeds je content uit.

[ Voor 3% gewijzigd door Verwijderd op 15-03-2006 08:27 ]

[Verwijderd]

een hele tijd, kan dat ook bijv een dag lang zijn? en zie je dan niet steeds het 'page loading' balkje onderin IE?

gordijnstok: flash.. tja.. ik ben een purist, sorry maar als het echt niet anders kan wil ik het toch wel overwegen.

ik heb nu een 'oplossing' met persistent sockets; met een elke 5 seconden refreshende php in een iframe, die de socket dus weer oppikt en elke keer opnieuw de laatste 20 regels van de chat op het beeld zet. probleem is dan dus wel dat die 20 regels elke 5 seconden uit de database moeten worden gequeried (immers, elke refresh worden slechts de nieuw bijgekomen messages opgepikt) dus ik weet niet of de server beheerder daar zo blij mee is.

[Verwijderd]

Verwijderd schreef op woensdag 15 maart 2006 @ 16:32:

gordijnstok: flash.. tja.. ik ben een purist, sorry

Ik zou dat "ongeschikt voor dit soort werk" willen noemen.

ik heb nu een 'oplossing' met persistent sockets; met een elke 5 seconden refreshende php in een iframe, die de socket dus weer oppikt en elke keer opnieuw de laatste 20 regels van de chat op het beeld zet. probleem is dan dus wel dat die 20 regels elke 5 seconden uit de database moeten worden gequeried (immers, elke refresh worden slechts de nieuw bijgekomen messages opgepikt) dus ik weet niet of de server beheerder daar zo blij mee is.

Om een enkele query die elke 5 seconden 20 records ophaalt zou ik me maar niet druk maken. Dat is echt helemaal niks.

Zoals ik al eerder zei is PHP hier eigenlijk helemaal niet zo geschikt voor. Maar je hóéft niet te luisteren natuurlijk.

[Verwijderd]

ok dan ga ik voor de 5 seconden methodiek

ik wil best luisteren hoor.. jullie vinden me ongetwijfeld eigenwijs .. maar.. maar wat ? tja
wat doe je er aan.

ondanks mijn eigenwijsheid stel ik alle reacties zeer op prijs hoor

[maartenba]

Je kan ook zoals www.meebo.com werken: zij doen eigenlijk constant een XML Request (om de x milliseconden), die ze op de server een tijdje openhouden door lege info terug te sturen, en als er toevallig data beschikbaar is krijg je die mee. Soort polling dus, maar meer frequent en met langere timeout.

edit:

Kheb de link teruggevonden: http://www.plasser.net/blog/continuous_ajax_requests/

[ Voor 27% gewijzigd door maartenba op 16-03-2006 08:55 ]

[Verwijderd]

Dat is ook een open HTTP connectie, dan ga je uit dat de readystate niet de waarde 'complete' bereikt (of 4 bij onreadystatechange) tot het moment dat de connectie wordt gesloten.

Echter, staat me er iets van bij dat IE hier totaal niet mee om kan gaan en het daadwerkelijk niet pikt.

[Verwijderd]

toch het proberen waard..