Ist es irgendwie möglich zB Firefox/Chrome dazu zu bringen, auf eingehende Nachrichten zu lauschen und reagieren (unter Windows)? Sprich, ich schreibe mir was in Python/C/Perl/wasauchimmer was im Hintergrund regelmäßig gestartet wird. Das soll dann Daten (meinetwegen json) an den Browser senden können die ich in einem Tab mit zB JS auswerten kann. Mein erster Gedanke war, im Script einen rudimentären Webserver/-socket zu starten, aber dann muß das JS im Browser ja zu genau der Zeit pollen, wenn das Script läuft. Und wenn ich das Script idlen lasse bis eine Verbindung reinkommt, dann überlappen sich Instanzen wenn Browser/Tab mal zu sind. Außerdem muß ich bei mehreren Scripten dann auch noch verschiedene Ports verwalten. Plus der initiale Lag, denn ich kann ja nicht jede Sekunde x Ports überprüfen. Ach so, alles zusammen soll auf dem gleichen PC laufen, vielleicht macht es das leichter. In meiner Traumwelt hätte ich am Ende ein Verzeichnis mit einer HTML Seite und ein paar Skripten was ich so ohne Installationskram nutzen kann (ok, außer die Scripte die Aufgabenplanung eintragen).
Die meisten Browser unterstützen schon "push notifications" (google mal danach) . Wirst bestimmt schon auf der ein oder anderen Webseite gesehen haben: "Die Seite XY möchte ihnen Benachrichtigungen senden. Zulassen?" Dabei wird im Browser ein worker Javascript installiert, dass regelmäßig eine Webseite abfragt. Dein Perl/C wasauchuchimmer müsste allerdings über HTTP (ggf sogar verschlüsselt) erreichbar sein.
Ich glaube er will einen unsauberen Hack alla "script aufrufen -> öffnet Seite in Browser und nimmt Daten vom Skript entgegen, aber nur falls die Seite noch nicht offen ist" machen, statt da sauber einfach immer einen Server laufen zu lassen, und den als message bus zu verwenden. Einfach nur eine Seite starten und ein paar Daten mitgeben, da kann man an die Datei einfach Daten nach ner # anhängen. Man kann mit sendMessage und localStorage in gewissen Browsern mit ein paar hacks und ner zwischendatei Daten austauschen, empfehlen würde ich das aber nicht: a.html
1 | <script> |
2 | function sendMessage(key, message){ |
3 | localStorage.setItem(key, Math.random().toFixed(8).substr(2) + JSON.stringify(message||null)); |
4 | }
|
5 | if(!location.hash){ |
6 | window.addEventListener('storage', function(event){ |
7 | top.postMessage({ |
8 | what: 'storage', |
9 | key: event.key, |
10 | value: JSON.parse(event.newValue.substr(8)) |
11 | },"*"); |
12 | });
|
13 | }else{ |
14 | console.log(location.hash.substr(1).split(':',2), location.hash) |
15 | sendMessage(...location.hash.substr(1).split(':',2)); |
16 | window.close(); |
17 | }
|
18 | </script> |
b.html
1 | <script> |
2 | function receiveMessage(event) { |
3 | console.log(event.data); |
4 | }
|
5 | addEventListener("message", receiveMessage, false); |
6 | </script> |
7 | <iframe src="a.html" style="display:none;"></iframe> |
b.html öffnen, dann a.html#test:123 öffnen, in b.html in der Konsole
wird dann Object { what: "storage", key: "test", value: "123" }
ausgegeben.
Man kann die Seite dann aber nicht automatisch wieder schliessen...
Eine "sauberere Lösung" wäre wohl sowas wie selenium zu nehmen, wirklich
schön ist das aber auch nicht.
Gerald K. schrieb: > Warum nicht direkt über CUR HTTP Client abfragen? Wie soll mir curl helfen? Roland P. schrieb: > Die meisten Browser unterstützen schon "push notifications" (google mal > danach) . Danke! Werde ich mir ansehen. DPA schrieb: > Ich glaube er will einen unsauberen Hack alla "script aufrufen -> öffnet > Seite in Browser und nimmt Daten vom Skript entgegen, aber nur falls die > Seite noch nicht offen ist" machen, statt da sauber einfach immer einen > Server laufen zu lassen, und den als message bus zu verwenden. Ich möchte einfach eine HTML Seite als so eine Art GUI verwenden. Wenn die offen ist, würde ich dort gerne von den Scripten Statusmeldungen oä abliefern lassen. Automatisch öffnen will ich nichts. Dafür wären wohl Websockets da, aber wenn ich alles richtig verstehe dann muß ich jedes Skript als Windows-Service mit eigenem Port schreiben und installieren. Sowas ist mir für ein bisserl Hobby zu aufwendig.
du könntest auch einen vom Script unabhängigen webserver starten und den laufen lassen. Dein script läd seine Ergebnisse bei dem Server ab. Entweder als datei oder schreibts in eine Datenbank (hab ja keine Ahnung, was du eigentlich machst). Der webserver liefert einfach eine Seite aus, die alle sekunde oder so, guckt, ob was neues da ist (https://developer.mozilla.org/de/docs/Web/API/XMLHttpRequest/XMLHttpRequest) und aktualisiert die Felder der Seite entsprechend. Der Webserver könnte natürlich auch komplett selbstgeschrieben sein. Dann könntest du ihn auf eine Url mit dem ausliefern der Seite reagieren (/get für komplette HTML-Seite oder /get/key für einzelnen Wert (ohne HTML)) lassen und auf eine andere mit dem aktualisieren (set?key=value) der auszuliefernden Daten.
Gustl schrieb: > Dafür wären wohl Websockets da, aber wenn ich alles richtig verstehe > dann muß ich jedes Skript als Windows-Service mit eigenem Port schreiben quatsch. du kannst auch einen Server schreiben, der je nach parameter dir den gewünschten Wert zurückgibt. (siehe obige Antwort)
Ich habe es zwar erst entdeckt und noch nichts damit gemacht. Aber dieses "Node Red" könnte vielleicht was für dich sein. https://nodered.org/ https://youtu.be/vYreeoCoQPI
Vlad T. schrieb: > Dein script läd seine Ergebnisse bei dem Server ab. Entweder als datei > oder schreibts in eine Datenbank (hab ja keine Ahnung, was du eigentlich > machst). Einfaches Beispiel: ein Script kopiert jede Stunde eine Liste von Dateien (Backup). Im Browsertab sehe ich dann den 0-100% Fortschritt und am Schluß ob alles ok war. (Ja, gibt richtige Backuplösungen, aber ist nur ein Beispiel). Was Du beschreibst ist doch ein Polling wo der Browser sekündlich einen ajax Request an den Server schickt, der dann eine DB Verbinung aufbaut und einen Query macht. Pro Tag also 86400 mal, 86376 mal umsonst. Sowas (inkl Serverinstallation) wollte ich halt vermeiden und es gerne simpel halten. Daher dachte ich daß man wenigstens lokal irgendwie mit dem Browser direkt kommunizieren kann.
Gustl schrieb: > Pro Tag also 86400 mal, 86376 mal umsonst. na und? wenn man grob 1k pro request rechnet sind das 86MB pro tag. Wenns lokal ist, juckt es überhaupt nicht. ansonsten könntest du dir push oder das anschauen: https://www.developerdrive.com/pushing-updates-to-the-web-page-with-html5-server-sent-events/
Gustl schrieb: > Dafür wären wohl Websockets da, aber wenn ich alles richtig verstehe > dann muß ich jedes Skript als Windows-Service mit eigenem Port schreiben > und installieren. Nö, ist nicht nötig. So ein server kann z.B. auch ein simples python flask script sein, und sowas kann man auch starten, ohne dass es ein windows service ist. Die firewall muss es halt erlauben, falls du eine hast. Du brauchst ja nicht unbedingt für jedes Script einen neuen Server. Du könntest dann z.B. server starten -> darüber Seite aufrufen -> Websocket Verbindung zu aufbauen. Bei den Scripts dann einfach dem server mitteilen, was sie dem Browser sagen sollen, z.B. mit curl, oder in einen Fifo schreiben, den du im Server anlegst, oder sonst wie. Du könntest den Server auch so Konfigurieren, unter einer bestimmten URL das Script aufzurufen, z.B. localhost:8080/api/start/scriptname. Dann würde der Server am Schluss sogar selber wissen, ob das Script sich erfolgreich beendet hat, und du könntest den Server einfach stdout oder stderr des Prozesses per websocket an den Browser weitergeben, ihm quasy sagen '{"what":"script output", "script": "bla.py", "content": "some line the script has written to stdout"}'.
HTML kennt auch einen Meta Tag "refresh" damit kannst du die Seite alle paar Sekunden neu laden.
JJ schrieb: > HTML kennt auch einen Meta Tag "refresh" damit kannst du die Seite > alle > paar Sekunden neu laden. das ist aber mehr als krude. Dann flackert deine seite alle paar Sekunden. Außerdem holt man so immer die komplette Seite. mit einem Request nur die Daten zu holen und die einzelnen Felder der Seite zu aktualisieren ist viel sauberer und sparsamer
Der Poster hat das Prizip von client/Server noch nicht verstanden.
Joggel E. schrieb: > Der Poster hat das Prizip von client/Server noch nicht verstanden. <loriot>Ach?</loriot> Mir kommt es eher so vor, als hättest Du das Prinzip nicht verstanden da sich Dein "Serverhorizont" bei sowas wie apache, nginx, iis, etc erschöpft. In meinem Plan wäre einfach der Browser der Server, und das Script der Client. Aus den Antworten im allgemeinen ziehe ich aber den Schluss, daß Browser keine wirkliche Schnittstelle für eingehende Kommunikation haben. Bliebe dann halt Push oder SSE.
Frueher hat man fuer sowas einfach Java benutzt. Ich habe hier z.B. einen (Ethernet-)Terminalserver der per Browser kontaktiert wird, dann ein Javaapplet laedt, dass dann im Webbrowser ein serielles HP-Terminal emuliert. Dafuer hat das kleine Kaestchen dann tatsaechlich eine 25pol. Buchse. Dieses Beispiel nur, um zu zeigen, dass damit so ziemlich alles moegliche und scheinbar unmoegliche realisierbar ist.
Gustl schrieb: > In meinem Plan wäre einfach der Browser der Server, und das Script der > Client. Das geht aber nunmal nicht. Dein Zauberwort... Wie oben bereits erwähnt... heißt XMLhttpRequest oder kurz Ajax. Ein klitzekleiner Webserver und eine Scriptsprache deiner Wahl und gut ist. Ich habe so ein Server Info Fenster am laufen. Alle 500ms werden auf der Seite sämtliche Daten für RAM, CPUs, Nics und sowas aktualisiert. Mit Diagrammen, Progessbars etc... Übrigens, das beste Beispiel für Ajax ist immer noch die Börse mit ihren Kursen. Alles andere ist nur krude Frimmellei und macht mehr Arbeit als es sinnvoll ist.
Rene K. schrieb: > Das geht aber nunmal nicht. Dein Zauberwort... Wie oben bereits > erwähnt... heißt XMLhttpRequest oder kurz Ajax. Geht nicht gibt's nicht. Ist halt nur eine Frage des Aufwands. Man könnte ja auch den Browser patchen... > Ein klitzekleiner Webserver und eine Scriptsprache deiner Wahl und gut > ist. Ich habe so ein Server Info Fenster am laufen. Alle 500ms werden > auf der Seite sämtliche Daten für RAM, CPUs, Nics und sowas > aktualisiert. Mit Diagrammen, Progessbars etc... Wären für Dein Infofenster nicht Websockets besser? Wenn Du alle 0,5s per Ajax pullst, dann ist es anders rum besser. > Übrigens, das beste Beispiel für Ajax ist immer noch die Börse mit ihren > Kursen. Börsenseiten machen das übrigens schon lange per Websockets. Ist performanter und macht weniger Traffic.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.