Befehle auf Webseite serverseitig ausführen

[Daaron]

So.... und jetzt habt ihr dem TE bald alles haarklein vorgekaut und die Eigenleistung, die ich erzwingen wollte, ist nicht mehr nötig.

 

[Freezedevil]

Ich hab deswegen auch überlegt, ob ich es poste (daher auch die Stunde Zeitverzögerung zwischen den Posts). Warum soll ich aber aus meiner dann eh vorhandenen Lösung ein Geheimnis machen? An das nötige Engagement des TEs um hier selbst auf die Lösung zu kommen und somit wirklich was zu lernen glaube ich, nachdem was ich hier bisher gelesen hab, eher nicht mehr. Vielleicht war ich zu voreilig und tue dem TE Unrecht, aber wer weiß das schon...

 

[carom]

1. Wie sprichst du mit req.open("POST", '/', true); den Server an? Das funktioniert bei mir nicht, bis ich nicht für '/' ne IP und nen Port eintrage (anders kann ich mir das beim besten Willen auch nicht vorstellen)

Du scheinst das HTML-File bei dir lokal zu öffnen, anstatt es über Node ausliefern zu lassen. Wie er den Server anspricht? Na mit "/", dem Web-Root des "Origins".

2. Ich muss in die die Funktion unbedingt noch die folgenden Zeilen schreiben, damit das bei mir geht. Ich denke damit bin ich nicht der Einzige.

Wieder das selbe Problem... brauchst du nicht

edit:
also ich beziehe mich auf den geposteten nodejs-Code ... wenn du das HTML-File zwar auslieferst, den ajax-Call aber an einen anderen Port schicken möchtest, dann sieht die Sache anders aus.

edit2:
Da Websockets erwähnt wurden: die kann er nehmen, wenn er mit seinem Roboter bidirektional kommunizieren möchte, was ja nicht unüblich wäre.
Ansonsten spricht in diesem Szenario imho nicht viel für Websockets. Ziel war, die Komplexität des Servers klein zu halten, nicht die Übertragung selbst. Die gesparten Header-KB im Vergleich zu HTTP dürften in einer WLAN-Umgebung absolut irrelevant sein, ebenso die Latenz.

Als Blick über den Tellerrand: In einer eher wissenschaftlichen Anwendung, die nicht für die Breite Masse bestimmt ist (das Steuern eines Roboters gehört für mich dazu), könnten auch jSocket oder SocketJS zielführend sein, wenn man lowlevel Sockets in einem Webclient haben möchte. Beide Technologien sind Javascript-Bridges zu einer kleinen Actionscript 3 Anwendung bzw. einem Java-Applet im Browser, von denen der Benutzer nichts mitbekommt, die aber eine echte TCP-Socketverbindung zum Server aufbauen.

Wäre ich der TS, würde ich auf der gesposteten nodejs-Lösung aufbauen. Nodejs und der Raspberry Pi scheinen ja ganz gut zu harmonieren.

 

[Freezedevil]

Du scheinst das HTML-File bei dir lokal zu öffnen, anstatt es über Node ausliefern zu lassen.

Stimmt, da hatte ich nen Denkfehler drin. Meine beiden Probleme erübrigen sich dann natürlich. Hab eben noch nie was mit node.js gemacht und das daher nicht auf Anhieb durchschaut Danke für den Hinweis.