Php<>irc

Chaosengel_Gabriel

Erfahrenes Mitglied
Hallo Leute...
Ich werd langsam nen bissl größenwahnsinnig mit meinen Vorhaben, aber trotzdem will ich mein bestes tun, um alles, was mir durch den Kopf geistert zu verwirklichen :D

Also... Wie ihr in der Topic lesen könnt geht es mir um die Kommunikation mit nem IRC-Netzwerk... Und das via PHP...

Ich benutze ne OpenSource Klasse, um die antworten vom IRC zu handeln, allerdings is da keine wirklich hilfreiche Dokumentation bei :(

Das ist die Klasse: http://gabriel86.ga.funpic.de/Klassen & Skripte/SmartIRC-0.5.5.zip

Die Problematik die sich mir stellt is größtenteils, dass ich nicht richtig verstehe, was da vor sich geht...
Die Funktionen für die IRC-Befehle kapier ich und da werd ich noch die Funktionen für das vergeben von Halfop und Admin rechten hinzufügen...

Aber wie kann ich mir daraus nen eigenes IRC-Aplett bauen, also nen kleines Chat-System...

In den Beispielen wird gezeigt, wie ich eigene Bots schreibe, was ja auch funny is, aber was bringt mir der Bot, wenn kein User in der Channel kommt ^^

Ich möchte auch nur ungern weiterhin auf fertige Apletts wie PJIRC zurückgreifen, da es mit der Klasse ja möglich sein müsste, mit Unterstützung von Ajax, das selber umzusetzen...

Wäre cool, wenn sich jemand die Klasse anschauen könnte und mir vllt nen bissl weiterhelfen kann...
Nen kleiens Beispiel in bezug auf die Klasse oder so reicht schon, um mein Verständnis und Wissen zu erweitern ;)

THXLE
 
Ich würde abraten von einem PHP <> IRC Vorhaben, klar ist es möglich.. aber es wird deinen Server endlos stressen. Je mehr Personen darüber chatten desto Schlimmer. PHP ist für so etwas nicht gedacht und darum sind alle Lösungen keine richtigen.

Das Connection-handling hinzubekommen das jeder user seine eigene connection hat, die aber aufrecht erhalten wird, auch wenn die seite "fertig geladen" ist. Dann immer wieder darauf zugreifen zum nachrichten senden / empfangen... das ganze system ist einfach nicht komplett kompatibel. Dazu kommt noch das wenn User Fenster lange offen lassen, oder einmal irgendwie das beenden nicht 100% klappt die Threats ins unendliche weiterlaufen, und schnell Ressourcen aufressen.

Fast alles ist geigneter als PHP
Java z.B. Ein solches Applet zu verwenden ist ratsamer als PHP direkt zu verwenden. Diese werden Clientseitig ausgeführt und schießen im Zweifelsfall die Computer der User ab, nicht den Server.
 
Die ersten beiden Lösungen mit PHP und MySQL liefern nur nen PHP-basierten Chat... Sowas zu schreiben ist nicht schwer...

Die Argumentation leuchtet ein, lieber Michael, verfügbare Apletts wie PJIRC arbeiten ja auch nur mit Java, aber mein Problem dabei ist, dass ich nur wenig selber daran variieren kann...
Könnte ich den theoretisch mit der Smart-IRC-Klasse aktionen des Apletts hervorrufen... Also zB das automatische wechseln des CHannels ohne das Aplett neuzustarten...

So wie ich die Klasse verstehe kann ich damit ja Bots schreiben und diese Bots entsprechende Funktionen ausführen lassen...
Kann ich diese Funktionen auch auf den User anwenden...

Bei dem Java-Aplett wäre es praktisch, wenn ich das Context-Menü und ähnliches anpassen könnte, daher die überlegung das mit der Klasse komplett selbst zu lösen...
Und Java arbeitet doch eigentlcih auch nur mit einer permanenten Verbindung ins IRC pro User, sowie es letztlich mit PHP/JS auch wäre...
Das PHP dabei is ja nur zum parsen und action-handlen der Nachrichten...
Der Chat selbst liefe dann theoretisch mit JS, da ja auch nen Site-Reload nicht sein soll...
 
Vielleicht noch zwei Argumente für einen solchen PHP-IRC Chat.

Ich kenne von einem Kumpel das Problem, daß er sehr oft an verschiedenen PCs arbeitet auf denen weder eine JVM installiert ist, bzw wo keine Programme installiert werden dürfen. Teils verbindet er sich zum Internet über einen Proxy-Server, welcher nur HTTP GET/POST Anfragen verarbeitet, jedoch kein CONNECT für passthrough.
Hier wäre ein Java IRC Applet absolut nutzlos, weil es schlicht und ergreifend einfach nicht funktionieren würde (sei es wegen fehlender Software oder weil der Proxy entsprechend die Verbindung blockt).
Hier würde ein PHP basierter IRC-Chat funktionieren, da dieser sich auf Clientseite nur des HTTP-Protokolls bedient.

Ein zweiter Aspekt ergibt sich aus dem Ressourcenanspruch auf Clientseite. Der Benutzer benötigt lediglich einen JavaScript fähigen Browser. Mehr nicht. ER kann auf eine JVM oder etwaige Zusatzprogramme komplett verzichten.

Dem Problem mit unsauber getrennten Clients und demnach entstehenden Zombie-Verbindungen von PHP zum IRC-Server lässt sich sehr einfach Abhilfe schaffen, indem man den PING-Request vom IRC-Server bis zum Client durchreicht und dieser mit dem PONG antwortet. Tut er dies nicht, weil der Benutzer die Verbindung unsauber getrennt hat (Absturz des Browsers o.ä.) so wird auch die PING-Anfrage nicht beantwortet und der IRC-Server trennt wie gewohnt die Verbindung zum PHP-Client mit der Meldung "Ping timeout after x seconds". Das Gleiche passiert bei ganz normalen IRC-Clients auch, womit der PHP-Client konform arbeiten würde.

Ich persönlich sehe eine PHP-IRC Lösung als Fallback Alternative, wenn Java-IRC aus oben genannten Gründen nicht funktioniert. Somit hat man eine gute Balance zwischen den Benutzern die problemlos eine direkte Verbindung zum IRC-Server aufbauen können und zwischen denen, bei denen keine direkte Verbindung möglich ist.

Gruß

Evil2000

P.S.: Mal weiter gesponnen kann man mittels Session-ID und AJAX einen PHP-IRC bauen der die Verbindung sogar über mehrere Clientsitzungen offen hält und es so einem Benutzer ermöglicht über Nacht den PC abzuschalten und am nächsten Tag die Verbindung mittels AJAX wieder aufzunehmen und das Backlog der Nacht zu lesen.
 
Zuletzt bearbeitet:
Letzteres wäre dann fast die selbe Funktion wie die eines Bouncers... ;)

Der Hauptsächliche Gedanke meinerseits ist einfach nur, dass ich flexibler mit IRC arbeiten möchte, also zB. beim ändern eines TEILS der Seite per AJAX entsprechend dann auch nen automatischen /part - /join im IRC auszulösen und ähnliches...

Man hat mit PHP und Co leider so ziemlich garkeinen zugriff und null kontolle über Java-Applets...
 
Zurück