Ich habe heute zweimal gelesen, dass der integrierte Webserver bei meinem Player recht praktisch, aber noch zu rudimentär ist. Wenn ich den ausbauen möchte, komme ich aber nicht drumherum, das Konzept zu überarbeiten.

Bisher läuft die Steuerung des Players über Links mit bestimmten Parametern. Klickt man z.B. auf den Link "Stop" wird im Browser die Seite komplett neu geladen, und der Player führt (serverseitig) die Aktion "Stop" aus. Das würde ich gerne besser gestalten - Stichwort wäre hier wohl Ajax. Aber bevor ich damit anfange, möchte ich sicher sein, dass ich damit durchkomme und die richtige Technik einsetze. Für Alternativen bin ich dankbar.

Wenn ich das richtig verstehe, muss ich dann durch den TIdHTTPServer auch ein Javascript-File ausliefern. Im OnClick eines Links/Buttons/whatever stoße ich dann einen xmlhttprequest an. Wenn die Daten fertig geladen sind, wird dessen Callback onreadystatechange ausgeführt, in dem ich dann per document.getElementById(my_ID) und z.B. innerHTML den passenden Teil der bereits geladenen Seite durch die neuen Daten ersetze.

Was der Server bei so einem Request zurückliefert, ist relativ wurscht, wenn ich das richtig verstehe. Das Javascript ist dafür verantwortlich, dass das richtig geparsed und in den HTML-Code eingefügt wird. Dieses Tutorial sieht für den Anfang recht vielversprechend aus, ist aber auch schon ca. 5 Jahre alt - vielleicht also schon komplett überholt.

Habe ich das so richtig verstanden, oder ist das totaler Murks? Und gibt es evtl. andere Techniken, die besser für sowas geeignet wären? Das ganze soll später in sämtlichen Browsern laufen - auch und vor allem auf mobilen Geräten wie iPhone, iPad, Android, etc.pp. Gibt es irgendwelche Fallstricke, auf die ich im Vorfeld achten sollte?

Je nachdem, wieiviel Aufwand Du dir für die Implementierung der AJAX-Hol-mir-mal-die-Daten-Schnittstelle treiben möchtest, kannst du Teile davon auch an ein Framework wie jQuery MooTools oder ähnliches auslagern. Diese kümmern sich dann zum einen um eine Reihe grafischer Geschichten im Browser (Stichwort UI), aber auch im Backend darum, dass das AJAX sauber die Daten an den Server überträgt.

Als Datenformat bietet sich JSON an, da dieses die wenigsten Probleme bei der Behandlung in Browsern macht. Auch Cross-Domain ist hier u.U. weniger Reibung zu erwarten. Im Zweifelsfall bitte die Specs für die ACL-Header vom W3C durchlesen, da steht ein wenig was bzgl. Preflight-Requests zur Ermittlung von Berechtigungen. Neben GET, POST und ggf. DELETE und PUT müsstest du also in jedem Fall auch OPTION-Requests behandeln können. Mehr dazu in besagter Spec; ein Beispiel für PHP kann ich Dir geben (hab sowas ähnliches für "GeSHi as a Webservice" mal gebaut).

Als Format für deine API bräuchtest du IMHO zwei Interfaces, die man aber recht gut parallel pflegen kann: Während das erste Interface eine REST-API bereitstellt (die also nur reine JSON-Antworten liefert), stellt die zweite API deine bisherige Web-Oberfläche dar, wobei entsprechend z.B. nach dem Add eines Tracks zur Playlist einfach ein Redirect zu einem "GUI-Aufruf" gemacht werden kann, die die entsprechende Playlist im Browser wieder anzeigt.

Zusätzlich empfehle ich Dir noch die Verwendung von Notifications, denn HTML5 rocks! (Puns intended!)

P.S.: Ja, ich weiß, der Thread ist alt, aber ich denke, Gausi kann mit den Stichworten seine bisherige Implemntierung noch verbessern.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Ja, auf jQuery bin ich dann auch gekommen. Da muss ich mich um einiges weniger kümmern und muss auch nicht so tief in Javascript einsteigen.

Wirklich umfangreich ist das auch nicht, was ich da mit Ajax mache. Und ob das alles so vernünftig ist, weiß ich nicht. Ein Aufruf an den Server ist z.B. "GetPosition", und als Antwort kommt dann nur ein String zwischen "0" und "100", der den Fortschritt im aktuellen Titeln in Prozent angibt. Andere Calls liefern Teile von HTML-Code zurück, die dann in die Seite eingebaut werden. Das ist alles eher dahingefrickelt. Aber da der Funktionsumfang, der über Ajax läuft, sehr eineschränkt ist (weil der Server generell eine sehr spezielle Funktion hat), ist das fürs erste ok.

Eine serverseitige Scriptsprache möchte ich da nicht einbauen. Das wäre zwar an ein oder zwei Stellen schön gewesen, würde den Code aber doch etwas viel aufblähen.

Wäre es da nicht sinnvoller, dass getPosition z.B. sowas hier zurückgibt?



Dann könnte das JS im Browser daraus auch die Anzeige aktualisiern, wenn der Titelwechsel verpasst wurde, Außerdem wird man dann unabhängig von der mitgelieferten UI. Frag Martok mal, wie man solche APIs am besten aufbaut, der baut da ja grad an [ungenanntes Projekt] einiges ...

Sprich die GUI die dein Webserver normal ausliefert, sollte nur eine Art "minimaler Client" für diese API sein.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Naja, die Position wird regelmäßig abgerufen (1Hz). Die Titelinformationen nur dann, wenn neuePos < altePos.

Die GUI kann ja auch nachträglich angepasst werden. Dafür habe ich ein rudimentäres Template-System zusammengebastelt. Wenn ein pfiffiger User da gerne nicht jquery, sondern was anderes nutzen will, sollte das auch gehen, ohne den Delphi-Code anpacken zu müssen. Aber wie gesagt: Das läuft aktuell ganz gut, also wird da jetzt nichts mehr dran geändert.