WebGadget als Ersatz für native GUI

[Mijikai]

Das ganze hört sich schon interessant an.
Mit Javascript kenn ich mich leider überhaupt nicht aus.
Wenn das ganze jedoch Funktioniert würde ich mich über Beispiele freuen.

[uweb]

Wenn das ganze jedoch Funktioniert würde ich mich über Beispiele freuen.

Troax hat ja schon eine praktikable Lösung angeboten.

Hat er?
PBExpresServer - Lightweight PureBasic Webserver & Framework?
Das kam bei mir gar nicht so an. Ich dachte er hätte einen Weg zum Selbermachen aufgezeigt.

... wobei da doch noch um einiges mehr dran hängt.

Aber dann ist der Weg zu SSL, WebDAV, ... vielleicht auch nicht mehr weit...


Ich fürchte kurzfristig sollten wir nicht all zu fest damit rechnen.
Vielleicht wäre ein einfacher (nur auf den Zweck gerichteter) Konfigurator&Manager für NGINX / Apache (portable?) in Verbindung mit z.B. PBElectron auf Basis von PBExpress realistischer?

[TroaX]

Mein Konzept-Name dafür war allerdings PureLectron (damit es nicht immer PB ist ).

NGINX, Hiawatha oder Apache mitzuliefern ist meiner Meinung nach schlicht vollkommen overpowered. Noch dazu würde so auch immer ein zweiter Prozess mitlaufen und wenn der abfliegt, dann kann es zu unschönen Seiteneffekten kommen. Außerdem müssten dann die Routinen per CGI/FastCGI eingebunden werden, was dann zu einem dritten Prozess führt. Der Overhead ist unnötig. Der Server soll ja nur als Kommunikationsschnittstelle zwischen WebGadget und den Purebasic-Prozeduren arbeiten. Da kann man dann lieber einen eigenen Webserver schreiben der das erledigt und im gleichen Prozess arbeitet. Das ist viel handlicher. Und ein Webserver gehört nun wirklich nicht zu den komplexesten Themen (siehe Atomic-Webserver Example). Das Teil hat sogar ein integriertes Directory-Mapping, wenn auch gleich der Headerparser Müll ist

So lange der Webserver nur auf localhost hört, kommt da von außen niemand ran. Die Kommunikation findet Systemintern statt. SSL/TLS, WebDAV und Co. sind einfach nicht nötig. Einen PBEmbedableExpressServer (Was für ein Name ) ist da schon eine gute Idee. Und ein weiterer Vorteil: Er kann über den zurückgemeldeten Header die Same-Origin Regel für HTTP-Request innerhalb Javascript um eine selbstdefinierte Domain erweitern, wodurch sich aus dem Javascript-Kontext heraus auf externe Webservices zugreifen lässt. Die ganze Welt der API's steht einem offen ... Ok jetzt werde ich rallig. Ich glaube ich lege das PHP-Projekt nochmal zur Seite

[uweb]

Ja, WebDAV steht auf meiner persönlichen Wunschliste bei einer ganz anderen Baustelle - passt nicht ganz zum Thema.

SSL wäre aber nicht nur dafür sinnvoll. Damit könnte man z.B. sein PB-Programm (auf dem Homeserver) unterwegs mit dem Handy steuern - bzw könnten es alle Familienmitglieder tun (Multi-Client - Multi-User).

Es gab ja schon einige Ansätze zur Web-GUI und auch schon SSL (cryptlib - engl. Forum) aber die rundum-sorglos Lösung habe ich noch nicht entdeckt. Also freue ich mich auf Deine Lösung und würde mich natürlich auch über Beispiele freuen.

[TroaX]

Web-GUI für den Desktop ist da aber auch ein bisschen was anderes. WebDAV steht für sich allein und benötigt kein Backend. Man bekommt für z.B. NGINX ein Plugin, um WebDAV zu realisieren. Wenn man SSL nutzen will, dann baut man sich die Webanwendung mit CGI/FastCGI und lässt sie ebenfalls über NGINX und Co. Laufen. Da ist eine PB interne Lösung das Interface für einen Vollwertigen Webserver. Und dies existiert mit CGI/FastCGI bereits.

[TroaX]

Ich habe mir jetzt noch etliche Gedanken gemacht und die Frage gestellt, warum es überhaupt das Webgadget sein muss. Was spricht dagegen, einfach den Default-Browser zu verwenden? Ich habe mal das ganze getestet. Wenn ich jetzt mit z.B. FastCGI eine kleine API schreibe und beim starten des FastCGI-Prozesses z.B. RunProgram("http://localhost:12345/") verwende, wird der Browser gestartet und holt dann direkt ein auf Webtechnologien basiertes UI ab. Die API des (noch) FastCGI-Server kann dann zur Interaktion eines nativen Backends genutzt werden. Nebenbei prüft der Server mit ProgramRunning ab, ob die Browser-Instanz noch läuft. Wird der Browser bzw. Tab (je nach Browser) geschlossen, wird der Server ebenfalls beendet.

Noch dazu stehen einem jede Menge Funktionen aus dem Browser zur Verfügung (Druckdialog, Screenshot-Tools etc.). Vielleicht wäre das eine etwas angenehmere Möglichkeit. Denn ich glaube nicht, das wir in den nächsten X Jahren mal unter Windows Webkit als Webgadget haben

[Kiffi]

Was spricht dagegen, einfach den Default-Browser zu verwenden?

in meinem Fall brauchte ich eine Kommunikation mit der seriellen Schnittstelle. Das lässt sich mit einem per RunProgram() gestarteten Browser nicht bewerkstelligen. Deshalb musste ich auf Electron ausweichen.

Grüße ... Peter

[TroaX]

Die Verbindung mit der seriellen Schnittstelle baust du auch mit dem Backend auf und nicht mit dem Frontend. Genau deswegen brauchst du ja auch Electron. Electron liefert das Backend in Form von Node.JS direkt mit und genug Packages, die mit der seriellen Schnittstelle arbeiten können, gibt es genug im NPM.

Da Frontend und Backend strikt getrennt sind, läuft es mit meinen Versuchen auch nicht anders. Ich implementiere die Prozedur für die serielle Schnittstelle in Purebasic, verbinde sie mit dem Router (aktuell PBExpress), spreche sie mit einem Request aus dem Frontend heraus auf die Route an und das native Backend aus Purebasic verarbeitet die Informationen und liefert sie als JSON zurück ans Frontend. Es spricht also absolut nichts dagegen. Man muss sich nur verinnerlichen, das man die Routinen, die mit Hardware und Betriebssystem kommunizieren in Purebasic schreiben muss, während für das UI HTML, CSS und JS verwendet wird

Der einzige wirkliche Unterschied ist, das Electron fertig ist, ein Chromium-Gadget und die V8-Engine verwendet und dadurch teils Frontend und Backend direkt kommunizieren können. Dafür kann nachher die PB-Variante deutlich schneller arbeiten, wenn man es denn richtig implementiert.

[Kiffi]

Der einzige wirkliche Unterschied ist, das Electron fertig ist

das reicht mir als Argument

Grüße ... Peter

[TroaX]

Der einzige wirkliche Unterschied ist, das Electron fertig ist

das reicht mir als Argument

Grüße ... Peter

Zumindest fürs erste