Kommunikation zwischen Browser und Programm

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.

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:
> 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.

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.

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.