Not logged inClonkspot Forum
Forum Home Help Search Register Login
Up Topic Deutsch / Miniblogs / Sulphur
1 2 Previous Next  
- - By B_E (More than 200 posts.) Date 05.06.2014 01:11
Hi zusammen, das hier ist ein Miniprojekt von mir und geht eher an die Entwickler:

ich habe eine kompakte Library für PHP geschrieben, um das Parsen von Spielreferenzen des Masterservers etwas einfacher zu machen, alles bisher ist unter GitHub und auch von Packagist für Composer erhältlich ($ composer require beheh/sulphur). Ich kann mir vorstellen dass nicht viele etwas damit anfangen können, aber unter anderem kann man damit ähnliche Dinge wie die CMC-Seite tun und laufende Spieler filtern, man sollte sich dann aber vielleicht über Caching Gedanken machen.

Was noch nicht drin ist, aber nach den Diskussionen neulich auf jeden Fall kommt, ist korrektes Behandeln des Encodings. Mein alter Masterserver hatte damit auch immer Probleme, und das OpenClonk-Liga-System scheint auch seltsam damit umzugehen - daher versuche ich eine Referenzimplementierung für das Parsen von Referenzen zu bauen. Weiterhin kommen noch ein paar Methoden hinzu, um direkt auf Ressourcen und Spieler zuzugreifen, damit man z.B. schnell leere Szenarien oder bestimmte Hosts ignorieren kann.

Beispielcode ist auch in der Readme, aber die Grundlagen sind:

// fetch masterserver response
$response = Sulphur\ResponseFactory::fromUrl('league.clonkspot.org');

// iterate through all games currently in lobby
foreach($response->where('State')->is('Lobby') as $reference) {
    echo $reference->Title.' is now open!';
}

// show comment of first game containing "CMC" (case insensitive)
$references = $response->where('Title')->contains('cmc', true);
echo $references[0]->Comment;

// show title of first running league game
$references = $response->where('State')->is('Running')->where('League')->exists();
echo $references[0]->Title;


Falls es Fragen, Feedback oder Wünsche gibt einfach hier reinschreiben.
Parent - By Gecko (More than 500 posts.) Date 05.06.2014 12:39
Sehr schickes Ding! Und sehr praktisch. Super sowas bereitzustellen.
Imo Top! :)
Parent - - By Luchs (More than 1000 posts.) Date 05.06.2014 15:45
Ich hatte schon drüber nachgedacht, ob es nicht sinnvoll wäre, die Masterserver-Antworten alternativ auch als JSON bereitzustellen. Das würde solche Anwendungen viel einfacher machen, da man nicht erst noch das etwas seltsame Clonk-ini-Format parsen muss.
Parent - - By B_E (More than 200 posts.) Date 06.06.2014 11:49
Klar, aber das müsste erstmal jeder Masterserver machen. Es ist eine Sache wenn ein spezieller Server das macht, aber eine Library wird immer dann die meisten und korrektesten Daten liefern wenn sie das gleiche Format "spricht", das auch die Clonk-Engine nutzt und damit per Definition auf jedem Clonk-Masterserver funktioniert. So kompliziert ist das Format dann auch wieder nicht.
Wenn ihr aber speziell für Clonkspot z.B. eine Live-Darstellung bauen wollt die direkt per JSON live den Masterserver abfrägt würde sowas imho Sinn machen.
Parent - - By Luchs (More than 1000 posts.) Date 06.06.2014 13:21
Naja, tatsächlich gibt es ja bald nur noch eine Masterserver-Implementierung, die sowohl für OC als auch für CR im Einsatz ist. Für obskure Alternativserver ist der Nutzen von automatisierten Abfragen eher gering.
Parent - - By B_E (More than 200 posts.) Date 06.06.2014 13:54 Edited 06.06.2014 13:58

>obskure Alternativserver


Solange der Source dafür nicht öffentlich ist sehe ich immer noch akuten Bedarf für alternative Masterserver. So toll das Clonkspot/OpenClonk-Projekt auch sind, ein offener Masterserver ist meiner Meinung nach für ein offenes Spiel erforderlich, vor allem wenn sich die Implementierung in Zukunft ändert und um für CR z.B. alternative Ligen (z.B. für Wettbewerbe) bereitzustellen (auch, falls Clonkspot eines Tages unerwartet so wie Clonk.de aufhören sollte). Es geht mir im Rahmen von OC auch etwas um das Prinzip der Entwicklung eines "Open"-Spiels.
Ich hatte auch schon mehrfach im OpenClonk-Forum nach einer Veröffentlichung des Source gefragt, aber weil das anscheinend teilweise noch unter RWD-Lizenz steht habe ich dort immer nur negatives Feedback bekommen.

Und so obskur alternativer Masterserver-Source auch sein kann, ohne eine offizielle Implementierung ist das immer noch besser als was man sonst hat - nämlich gar nichts.
Parent - By Nachtfalter (More than 1000 posts.) Date 06.06.2014 14:57

>(auch, falls Clonkspot eines Tages unerwartet so wie Clonk.de aufhören sollte)


Niemals!!
Parent - - By Luchs (More than 1000 posts.) Date 06.06.2014 23:15
Kein Stress - der Ligacode ist bereits frei lizensiert und wird auch in näherer Zukunft veröffentlicht werden.
Parent - - By Kanibal (More than 200 posts.) Date 18.11.2014 19:33

>Sind Sie sicher, dass Sie wirklich auf eine so alte Nachricht antworten wollen?


Ja!
Parent - - By Luchs (More than 1000 posts.) Date 18.11.2014 19:37 Edited 18.11.2014 19:40
Ich habe den Code tatsächlich schon veröffentlicht. Eigentlich wollte ich auch zuerst noch etwas aufräumen, aber dazu werde ich wohl erst mal nicht kommen.

Eine Idee für die Zukunft ist, Redis nicht nur als Cache zu verwenden, sondern Spielupdates via dessen Pub/Sub System zu verbreiten und dann einen Websockets-Endpoint zu haben, an dem man live die Spiele bekommt.
Parent - - By Zapper (More than 500 posts.) Date 18.11.2014 20:00

>Eine Idee für die Zukunft ist, Redis nicht nur als Cache zu verwenden, sondern Spielupdates via dessen Pub/Sub System zu verbreiten und dann einen Websockets-Endpoint zu haben, an dem man live die Spiele bekommt.


Oder ZMQ!
Parent - By Luchs (More than 1000 posts.) Date 18.11.2014 20:09
Ja, ginge natürlich auch. Redis ist nur tatsächlich schon in Einsatz in der Clonkspot-Liga für das Rate-Limiting und um die Spielelisteneinträge zu cachen. In der alten Liga ging ersteres durch einen seltsamen PHP-Opcode-Cache, der mittlerweile nicht mehr existiert und letzteres in MySQL, was bei uns zu Encoding-Problemen geführt hat.
Parent - By B_E (More than 200 posts.) Date 19.11.2014 00:24

>Ich habe den Code tatsächlich schon veröffentlicht.


Wuhu, na also!
Parent - - By Zapper (More than 500 posts.) Date 06.06.2014 18:41
Der Profi würde jetzt kommen und einfach JSON Support in die Clonkengine ein bauen und alles auf JSON umstellen!!!
Parent - By Kanibal (More than 200 posts.) Date 06.06.2014 18:55
Ich hatte eher an protocol buffers gedacht, aber ja, die Idee hatte ich auch schon. :tongue:
Parent - - By Luchs (More than 1000 posts.) Date 06.06.2014 23:16
Wobei da der Gewinn ja nicht so groß ist, weil JSON-Parsing nicht schon direkt integriert ist.
Parent - By Zapper (More than 500 posts.) Date 06.06.2014 23:44
Gibt ja genug davon
Parent - By B_E (More than 200 posts.) Date 18.11.2014 15:44
Ich hab das ganze mal wieder aktualisiert, ein paar Tests hinzugefügt und Fehler behoben. Im OpenClonk-Forum war neuerdings der Wunsch nach einer Masterserver-Anzeige auf der Startseite gekommen, ich hatte jedoch leider noch keine Zeit, mich damit zu beschäftigen. Ursprünglich wollte ich das direkt mit Zugriff auf die Masterserver-Datenbank machen, aber ich glaube dass das mit Sulphur einfacher und modularer extern geht. Falls da jemand was bauen will freuen die sich bei OpenClonk für ihre Startseite bestimmt. Die Version ist jetzt außerdem auf 1.0.0 gelandet, also sehe ich das ganze als stabil an.
Parent - - By DMan (More than 200 posts.) Date 07.12.2014 14:45

>Install Sulphur by using composer.


Was ist, wenn man Composer nicht hat? Einfach die ZIP runterladen? Und wofür ist der Eintrag auf packagist.org?
Parent - By Luchs (More than 1000 posts.) Date 07.12.2014 15:25
Dann installierst du zuerst Composer? Ernsthaft, es gibt eigentlich keinen guten Grund auf eine vernünftige Abhängigkeitsverwaltung zu verzichten.
Parent - - By B_E (More than 200 posts.) Date 09.12.2014 13:17
Du kannst theoretisch einfach den Code in ein Verzeichnis packen, und alle Dateien in src/ inkludieren. Aktuell werden keine Abhängigkeiten genutzt, aber das kann sich jederzeit ändern.

Aber:
- Composer übernimmt das Autoloading (also "intelligente" includes)
- Mit Composer kannst du ganz leicht viele verschiedene Bibliotheken von Packagist in deinem Projekt nutzen
- Die Bibliotheken können mit Composer einfach aktualisiert werden
- Zur Not geht das auch ohne Kommandozeile auf dem Server, indem du das lokal machst und das vendor/-Verzeichnis hochlädst

http://getcomposer.org
Parent - - By DMan (More than 200 posts.) Date 09.12.2014 16:50

>Und wofür ist der Eintrag auf packagist.org?


Und (wie) kann man per Composer runterladen?
Parent - - By Luchs (More than 1000 posts.) Date 09.12.2014 20:59
Na so wie es in der Readme direkt unter dem von dir zitierten Satz steht.
Parent - - By DMan (More than 200 posts.) Date 11.12.2014 14:05
Ich meinte nicht das auf GitHub sondern das auf packagist.org. Und ich würde gerne immer noch gerne wissen, was das überhaupt ist.
Parent - - By B_E (More than 200 posts.) Date 11.12.2014 15:20
Das ist im Prinzip einfach ein öffentliches Repository, dass die Metadaten von GitHub (oder sonstwo) zieht.

Ich entwickele lokal -> commite lokal -> pushe die Commits auf GitHub -> erzeuge auf GitHub einen Release -> Packagist zieht sich eine Referenz auf den Release

Toll ist das, weil du jetzt in der composer.json nur noch eine Zeile einbauen musst, nämlich "beheh/sulphur": "1.1.1"" in der require-Sektion. Weil Composer eng mit Packagist zusammenarbeitet, musst du gar nicht wissen ob das auf GitHub/sonstwo ist - Packagist weiß das und gibt dir daher einfach die richtige Version. Falls ich eines Tages auf eine andere Plattform umziehe, geht Packagist immer noch, ich muss meine Referenz dort updaten. Weiterhin kannst du genau die Version angeben, die du haben möchtest, und ich kann beliebig andere Bibliotheken vorraussetzen, falls es denn mal dazu kommt (z.B. um das Abrufen von einem anderen Server mit einer weit verbreiteten Bibliothek zu machen). Composer kümmert sich auch da dann drum, dass immer die Version da ist, die meine Bibliothek braucht.

Das alles (und viel mehr) gibt es übrigens auch in diesem tollen Artikel zu lesen.
Parent - - By DMan (More than 200 posts.) Date 13.12.2014 15:05
Also einfach das von GitHub mittels Composer runterladen und in der composer.json beheh/sulphur": "1.1.1" (Frage wegen Anführungszeichen) reinschreiben? Und was ist, wenn du aktualisierst? Ist ja jetzt z.B. schon 1.1.2 vorhanden.
Parent - - By Luchs (More than 1000 posts.) Date 13.12.2014 15:18
Composer lädt dann tatsächlich von packagist, aber das ist ja egal. Composer müsste auch einen Befehl haben, der automatisch den Eintrag in der composer.json macht.

Wenn du das in der Form (nur die Version) schreibst, bekommst du immer exakt dieses Paket.
Parent - - By DMan (More than 200 posts.) Date 13.12.2014 15:25
Also einfach ab und zu schauen, ob's ne neue Version gibt und überschreiben, oder?

Und hab jetzt noch ne Frage zur Installation. Hätte das jetzt so gemacht:
1. update / upgrade
2. Install via. cUrl.
3. Datei (composer.phar) nach /usr/local/bin/composer verschieben

Aber wie dann weiter? Selbst in /var/www/ eine composer.json erstellen und was dann reinschreiben?
Parent - - By Luchs (More than 1000 posts.) Date 13.12.2014 15:29
Dafür gibt es `composer init`. Das stellt dir ein paar Fragen und du kannst deine Abhängigkeiten hinzufügen.
Parent - - By DMan (More than 200 posts.) Date 13.12.2014 15:30 Edited 13.12.2014 16:00
Edit: Gefunden.

PS: Die composer.phar heißt jetzt "composer" (ohne Extension) und befindet sich in /usr/local/bin. Soweit richtig?

Ich würde einfach B_E's composer.json runterladen. Die gibt's ja auf GitHub. Aber wohin damit?
Parent - - By B_E (More than 200 posts.) Date 13.12.2014 16:18

>PS: Die composer.phar heißt jetzt "composer" (ohne Extension) und befindet sich in /usr/local/bin. Soweit richtig?


Das kann gut sein, ja.

>Ich würde einfach B_E's composer.json runterladen. Die gibt's ja auf GitHub. Aber wohin damit?


Nicht ganz, das ist die von der Bibliothek selbst und für dein Projekt an sich nicht relevant. Ich habe dir ein Beispiel im anderen Post gegeben. Die Datei kommt einfach in das Wurzelverzeichnis deines Projekts.
Parent - - By DMan (More than 200 posts.) Date 13.12.2014 16:30
Ich habe kein eigenes Projekt. o:
Ich würde einfach nur gerne wie auf der CMC-Seite sowas für meine Seite einrichten.
Parent - - By B_E (More than 200 posts.) Date 13.12.2014 17:43
Ja, genau - das kleine bisschen "ist" dann dein Projekt.
Parent - - By DMan (More than 200 posts.) Date 13.12.2014 19:05
Muss ich dafür irgendwas bei GitHub oder sonst irgendwo erstellen? Hätte zwar nen Account aber naja..
Parent - - By B_E (More than 200 posts.) Date 13.12.2014 19:55
Nein, du brauchst einfach die anderswo genannte composer.json, damit Composer weiß, was er machen muss. Das mit der Projektbezeichnung kannst du weglassen, aber das wichtige sind die require-Zeilen.
Parent - - By DMan (More than 200 posts.) Date 13.12.2014 20:00
Und wo kommt die Datei hin? In den selben Ordner (var/www/...), wo später der PHP-Script landet?
Parent - - By B_E (More than 200 posts.) Date 13.12.2014 21:46
Genau. In dem Ordner wird dann auch das vendor/-Verzeichnis angelegt.
Parent - - By DMan (More than 200 posts.) Date 13.12.2014 21:55 Edited 13.12.2014 22:15
Okay. Aber kannst du mir das mit der autoload.php und dessen Einbindung nochmal in Ruhe erklären?
Die composer.json kann ich dann von dem Erstellungsort zum richtigen Verzeichnis verschieben, oder?
Parent - - By B_E (More than 200 posts.) Date 14.12.2014 00:38
Das ist ganz einfach: Die autoload.php wird mit der Ausführung von Composer automatisch für dich angelegt und kümmert sich automatisch um die Inkludierung der Dateien.

Du hast in simpelster Form in dem Verzeichnis deiner Anwendung (also per SSH, FTP, oder was auch immer dein Hoster anbietet irgendein /var/www/.../sonstwas) irgendwo:

|- index.php
|- composer.json


Mit "composer install" wird das dann zu

|- vendor/
    |- autoload.php
    |- <verschiedene Ordner>
|- index.php
|- composer.json


Deine index.php braucht jetzt nur noch "require 'vendor/autoload.php';" und hat dann dadurch Zugriff alle per Composer installierte Bibliotheken. Das heißt, du solltest dann genau die Beispielzeilen Code nutzen können, die in Sulphurs Readme sind.
Parent - - By DMan (More than 200 posts.) Date 14.12.2014 00:55

>Mit "composer install" wird das dann zu [...]


Also als erstes "composer require beheh/sulphur" in den Terminal eingeben, dann die erstellte composer.json in das Zielverzeichnis kopieren / verschieben und als letztes "composer install" ausführen? Da nochmal mit beheh/sulphur oder nur install?

Und zum Verständnis, wofür wird jetzt diese composer(.phar (ich hab's ja umbenannt))-Datei gebraucht?
Parent - - By B_E (More than 200 posts.) Date 14.12.2014 13:20

>Also als erstes "composer require beheh/sulphur" in den Terminal eingeben, dann die erstellte composer.json in das Zielverzeichnis kopieren / verschieben und als letztes "composer install" ausführen? Da nochmal mit beheh/sulphur oder nur install?


Nicht ganz, das sind zwei Wege um das gleiche zu erzielen.

Entweder du legst die composer.json per Hand an. Dann nimmst du die, die ich dir oben gegeben habe.
Oder du lässt Composer die composer.json selbst anlegen (da kommt das gleiche bei raus). Dazu führst du erst "composer init", und dann "composer require beheh/sulphur" aus.

Nach einem der beiden Wege führst du einfach nur noch "composer install" aus. Jetzt weiß Composer ja dank der existierenden composer.json, welche Bibliotheken heruntergeladen werden sollen, du brauchst also nichts weiter anzugeben.

>Und zum Verständnis, wofür wird jetzt diese composer(.phar (ich hab's ja umbenannt))-Datei gebraucht?


Die composer(.phar) ist das eigentliche Composer-Programm. Das kennt sich mit der composer.json aus und macht eben diese ganzen Dinge, wie vendor/-Verzeichnis erstellen, die gewünschten Bibliotheken aus require herunterzuladen und autoload.php zu erstellen.

Also nochmal zusammengefasst: Composer ist das eigentliche Programm, und braucht zur eigentlichen Funktion für dein Projekt eine composer.json. Die kannst du entweder selbst schreiben, oder Composer für dich anlegen lassen.
Parent - - By DMan (More than 200 posts.) Date 14.12.2014 14:15 Edited 14.12.2014 14:20
Ich habe gestern composer init probiert und dann abgebrochen, da ich nicht wusste, was ich da jeweils reinschreiben sollte. Deshalb hab ich auch gefragt, ob ich die composer.init von GitHub verwenden kann, da die Inhalte so ziemlich gleich waren. Hab dann composer require beheh/sulphur ausgeführt und habe die daraus produzierte composer.json in mein Hauptverzeichnis (/var/www/) verschoben (Script kommt vsl. auf die Hauptseite). Aber ok, dann nehm mal dein Beispiel weiter unten und führe dann composer install aus.

Edit:

>Du machst also jetzt nur noch "require vendor/autoload.php" und kannst dann alle Klassen von Sulphur (oder jeder anderen geladenen Bibliothek) mit Präfix nutzen, also etwa "new Sulphur\ResponseFactory"....


<?php require("vendor/autoload.php"); ?>, oder?
Und kannst du nochmal den Teil mit dem Präfix erklären?
Parent - - By B_E (More than 200 posts.) Date 14.12.2014 14:43

>Hauptverzeichnis (/var/www/) verschoben


Ich versuche bei meinen persönlichen Projekten so Miniseiten in Verzeichnisse abzukapseln - dann gibt es auf lange Sicht keine Konflikte. So entspricht das aber einfach einem riesigem Projekt, nämlich alles in deinem Webroot (geht natürlich auch).

><?php require("vendor/autoload.php"); ?>, oder?


Genau.

>Und kannst du nochmal den Teil mit dem Präfix erklären?


Das ist jetzt einfach eine Idee, die sich durchgesetzt hat: da dank Composer jetzt jeder Pakete einfach veröffentlichen kann gibt es natürlich Fälle, in denen mehrere Entwickler ihre Klassen gleich benennen (z.B. ist Sulphurs "ResponseFactory" nicht wirklich ein einzigartiger Name). Falls du jetzt mehrere Bibliotheken verwenden solltest, kannst du jetzt ganz einfach mithilfe des Präfixes festlegen, was du genau meinst. In Sulphur ist der Präfix einfach "Sulphur", das entspricht dem PHP-Namespace.

Zur Nutzung setzt du den einfach mit einem Backslash davor: $foo = new Sulphur\ResponseFactory...
Parent - By DMan (More than 200 posts.) Date 20.12.2014 13:35

>Zur Nutzung setzt du den einfach mit einem Backslash davor: $foo = new Sulphur\ResponseFactory...


Ist doch genau das, was oben eh schon steht, oder?

>// fetch masterserver response
>$response = Sulphur\ResponseFactory::fromUrl('league.clonkspot.org');


datei.php  {
include autoload
restscript
}
Mehr nicht, oder?
Parent - - By DMan (More than 200 posts.) Date 20.12.2014 13:35
pi@dPi ~ $ composer install
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating autoload files
pi@dPi ~ $

Aber ich sehe keinen neuen Ordner, der erstellt wurde. Hab glaube ich 2x composer.json, vllt. wurde nur beim ersten was erzeugt?

Jo. Es wurde im /home/pi/-Verzeichnis erstellt. Kann ich composer.lock und /vendor ins eigentliche Verzeichnis verschieben?
Parent - By Luchs (More than 1000 posts.) Date 20.12.2014 16:53
Die meisten Kommandozeilen-Tools arbeiten irgendwie mit dem aktuellen Ordner zusammen. Wenn du also `composer install` in deinem Home-Verzeichnis ausführst (angezeigt im Prompt durch die Tilde ~), dann sucht es in diesem Verzeichnis nach einer composer.json und erstellt dort die Dateien. Wenn du es woanders willst, dann wechsle zuerst in den richtigen Ordner mit `cd`.
Parent - - By B_E (More than 200 posts.) Date 14.12.2014 00:40

>Ich würde einfach nur gerne wie auf der CMC-Seite sowas für meine Seite einrichten.


Das ist auch eine tolle Sache, ich will das auch bald mit Sulphur machen. Aktuell ist das noch ein stark zusammengehacktes Script, weil Sulphur noch nicht Sub-Felder aus den Referenzen auslesen kann (d.h. z.B. Spielernamen gehen noch nicht). Das will ich aber demnächst einbauen, und dann landet der ganze Code dazu hier.
Parent - - By DMan (More than 200 posts.) Date 20.12.2014 16:35
Hast du das nicht für die CMC-Seite gebaut?
Parent - By B_E (More than 200 posts.) Date 20.12.2014 23:46 Upvotes 1
Ja, aber der Code ist noch sehr viel hackiger - ich wollte das endlich mal sauber und wiederverwendbar zusammenbauen.
Parent - - By B_E (More than 200 posts.) Date 13.12.2014 16:17
Nicht ganz: die Composer.json kann etwas mehr und da muss auch etwas mehr rein:

{
    "name": "dman/irgendeinprojekt",
    "type": "project",
    "require": {
        "beheh/sulphur": "~1.1"
    }
}


Der Befehl "composer update" lädt dir dann Sulphur runter und packt es in eine "vendor/"-Verzeichnis. Die Versionszahlen kann z.B. auch genaur eingegrenzt werden. ~1.1 heißt dabei das neueste aus der 1.1-Serie, also heute 1.1.2. Wenn es morgen 1.2.0 gibt, müsstest du das anpassen. Alternativ geht evtl. auch sowas wie >1, oder ~1 als Version, dann bist immer auf dem spätesten 1er-Release.
Das tolle ist jetzt, dass dir Composer im Vendor-Verzeichnis auch eine autoload.php gibt. Du machst also jetzt nur noch "require vendor/autoload.php" und kannst dann alle Klassen von Sulphur (oder jeder anderen geladenen Bibliothek) mit Präfix nutzen, also etwa "new Sulphur\ResponseFactory"....
Up Topic Deutsch / Miniblogs / Sulphur
1 2 Previous Next  

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill