nicht angemeldet
Hallo!
wie erklärst du deinem browser, dass er "lauschen" muss? wohl nur mit flash/java, PHP hat damit nix zu tun, und ist als serveranwendung IMO ungeeignet, denn wenn du schonmal Java verwendest kannst du mit einbem Servlet sehr viel mehr...
Das ist klar, ich habe ja gedacht Flash/Java auf den Clients, PHP auf dem Server. Du hast gemeint dafür könne man PHP vergessen.
PHP soll Daten an Clienten ausgeben. die clienten requesten PHP über HTTP und erhalten so auch antwort, es sei denn, sie haben externe software installiert. also: sie haben keine persistente verbindung, sondern nur eine request-basierte. jeder request ist unabhängig von einem anderen!
Ja, das ist das Problem welches man z.B. mit Flash und xml-sockets lösen kann - hoffe ich!
Kann das PERL? Oder gibt es da am besten ein standard-Linux-Tool für die Shell, das sowas kann? Vielleicht sogar curl?
wenn du perl auf einem Clienten ausführen kannst, so kann Perl das. In dem Falle kann aber auch PHP das. Du musst an die Möglichkeiten des Clienten denken, nicht an die des Servers.
Klar das man da ein Tool in Flash/Java braucht.
Fände es gut wenn Cheatah mal was dazu sagen könnte, den er ist es der immer so gegen PHP-Chats wettert und sich daher wohl auskenne sollte!
oh, ich glaube bei ihm würdest du viel schneller verstehen, _warum_ das nicht geht ;-)
Ich habe das schon einoge male von ihm gelesen, aber da gibg es nicht um dieses Problem, sondern einen Chat nur mit PHP und Browser zu realisieren - ohne Java/Flash. Ich frage mich jetzt was an einem Java-basiertem IRC Chat anders ist, als bei einem Flash/PHP Chat/Messanger, was hat der Javachat serverseitig, wie läuft die Kommunikation?
also, jetzt ganz von vorn:
der client hat nix ausser dem http-request-modul (das über TCP/IC läuft, darauf hat man jedoch _keinen_ Zugriff!), damit kann er zeitlich und zahlenmäßige, _von einander unabhängige_, unbegrenzte HTTP-Requests durchführen. Darauf bekommt er pro Request genau eine, _von den anderen Requests unabhängige_ Antwort (oder keine, wenn ein Timeout passiert).
Ja, das ist mir bewußt.
Es ist also purer Zufall, wenn beim Aufruf eines Scriptes auf dem Server eine Instant Message übertragen wird, denn dauerd muss ja ein neuer Request stattfinden. Der Server kann nämlich von sich aus NICHTS an den Client senden, sondern nur, wenn der anfragt. Das kann man _nicht_ automatisieren, zumindest nicht in annehmbarer Geschwindigkeit _und_ annehmbaren Komfort.
Dieses Problem ebenfalls!
Wenn jedoch ein Programm im Browser abläuft(Flash/Java) ist dieses in der Lage mit dem (einem anderen) Server in _persistenter_ Weise zu kommunizieren. Nur so erreicht eine Instant Message auf jeden Falll und genau einmal ihr Ziel.
Genau das war der Plan! ich glaube wir haben etwas aneinander vorbeigeredet ;-)
Im Augenblick weiß ich auch gar nicht mehr was ich anfangs wissen wollte ;-)
Jedenfalls sagst Du das man eine persistente Verbindung zwischen Flash/Java und PHP herstellen kkann, oder gehtz das nur mit PERL? Ist den eine oersistente Verindung überhaupt nötig? reicht es nicht wenn der Flash/Java Client an einem Port lauscht und der PHP Server bei einem Request von einem anderen Client diesen direkt an den entsprechenden Port dieses Clients weiterleitet? Und geht das nicht genauso gut mit HTTP wie mit IRC? Oder können in IRC die Clients DIREKT in Kontakt treten? Wie sieht das bei einem IRC Chat aus? Das ist dochj auch nur ein "echo-Server", der Requests von einem Client an alle in diesem Kanal angemeldeten Clients verschickt, die dann mit dem entscprechendem Program(mirc32, Java...) in einem best. Port lauschen....
Wo liegt denn jetzt der Vorteil von IRC?
Und kann PHP für meine Zwecke die Rolle des Servers übernehmen? Würde PHP auch die Rolle eines IRC Servers übernehmen können?
Viele Grüße
Andreas