CGI für Einsteiger

[mschnell]

Ich glaube, da täuscht Du Dich. Die Asymmetrie ist eine gewollte Eigenschaft von HTTP. (Bayeux und BOSH basieren auf Comet.) Bitte poste ein Link, wenn Du mehr weißt !

Websockets ( -> http://de.wikipedia.org/wiki/WebSocket ) laufen anscheinend nicht über HTTP ( -> http://www.pointsoftware.ch/de/websocke ... lications/) Damit scheitert das vermutlich an vielen Firewalls / Poxies, Die HTTP-Verbindungen schließen können und nur ein Öffnen von der Client-Seite zulassen. (Firmen-Firewalls lassen für User-Rechner keine Zugriffe von/nach außen durch, Proxies werden von IT-Abteilungen konfiguriert, und IT-Abteilungen erlauben nur dass, was absolut nicht zu verhindern ist. )

Browser wie Firefox dagegen scheinen Websocket zu unterstützen

Auf der Server-Seite muss es natürlich der Webserver unterstützen. Für Appache gibt es anscheinend ein "Modul" was man zu diesem Zweck installieren muss.

Websockt / HTML5 ist jedenfalls ein interessantes Thema (-> https://today.java.net/article/2010/04/ ... ies-part-2 )

Wie sieht es mit Lazarus aus (Das war ja die originale Frage) ? Gibt es da eine vorgefertigte Websocket-Unterstützung ? Soweit ich weiß nicht. Die Unterstützung für eine richtige mit HTML5 gebaute Web-Oberfläche, die sich mit dem Lazarus GUI Designer konfigurieren lässt, wäre eine sehr lohnende Erweiterung !

-Michael

[Christian]

Websockets sind HTTP Verbindungen die mit Upgrade zu ner Websocket Verbindung umgebaut werden somit gibts da keine Einschränkungen bezüglich Firewalls u.s.w.
Wie kommst du eigentlich darauf, die von dir verlinkte Wikipedia Seite erklärt das doch vernünftig ?!

Lazarus Unterstützung gibts wenn man nicht zu faul zum suchen ist auch.
https://github.com/cutec-chris/promet-e ... websockets

[mschnell]

Websockets sind HTTP Verbindungen die mit Upgrade zu ner Websocket Verbindung umgebaut werden somit gibts da keine Einschränkungen bezüglich Firewalls u.s.w.
Wie kommst du eigentlich darauf, die von dir verlinkte Wikipedia Seite erklärt das doch vernünftig ?!

Es ist eben kein klassisches HTTP wie es ein klassischer Firewall kennt, sondern eine Erweiterung, die auch beim Firewall (genau wie beim HTTP-Server, der ja ebenfalls transparent zwischen Browser und CGI-Programm steht) eine Erweiterung braucht, wenn er das verstehen soll und dafür konfiguriert werden kann, es weiterzuleiten.

Lazarus Unterstützung gibts wenn man nicht zu faul zum suchen ist auch.
https://github.com/cutec-chris/promet-e ... websockets

Das nicht "Lazarus" (für mich maßgeblich: fpc- und Lazarus- svn), sondern kommt woanders her. Danach habe ich nicht gefragt. Die Frage war, gibt es Unterstützung durch Lazarus in der Art, dass man den Lazarus GUI Designer verwenden kann.

Außerdem müssen die Events, die der Server nun mit Websocks an den Client schicken kann ja im Server durch irgendetwas hervorgerufen werden. Bei Lazarus wäre das z.B. ein TTimer. Wenn ein Lazarus-Programm keine lokale GUI hat, lässt sich bei den "Wiget Types", die momentan mitgeliefert werden, kein TTimer verwenden. (Ein solcher "Widget-Type" ist durchaus machbar - und steht auf meiner to-do-Liste - , gibt es aber im Moment noch nicht.)


-Michael

[Christian]

Kannst du deine These irgendwie belegen ? Warum sollte eine Firewall auf ein Upgrade einer bestehenden HTTP Verbindung irgendwie reagieren ?

Das nicht "Lazarus" (für mich maßgeblich: fpc- und Lazarus- svn), sondern kommt woanders her. Danach habe ich nicht gefragt. Die Frage war, gibt es Unterstützung durch Lazarus in der Art, dass man den Lazarus GUI Designer verwenden kann.

Nö, hast du nicht. Erklärt mir aber einige Kommentare hier.

Außerdem müssen die Events, die der Server nun mit Websocks an den Client schicken kann ja im Server durch irgendetwas hervorgerufen werden. Bei Lazarus wäre das z.B. ein TTimer. Wenn ein Lazarus-Programm keine lokale GUI hat, lässt sich bei den "Wiget Types", die momentan mitgeliefert werden, kein TTimer verwenden. (Ein solcher "Widget-Type" ist durchaus machbar - und steht auf meiner to-do-Liste - , gibt es aber im Moment noch nicht.)

Nein für soetwas nutzt man Threads. Und mit GUI Porgrammierung hat das nichts zu tun.

[mschnell]

Auch Lazarus-typische Thread-Funktionen wie TThread.Synchronize, TTthread, Queue und Application.QueueAsyncCall gehen momentan nur, wenn man eine GUI einbindet.

Klar gibt es auch andere Möglichkeiten, aber "modernes Object-Pascal" (von Florian Kaempfl geprägter Begriff) ist eigentlich für Event-orientierte Programmierung erfunden worden.

Bei einem normalen CGI braucht das Programm nur auf Anweisungen vom Browser, die über den HTTP Server reinkkommen zu reagieren. Da reicht ein einziges Ereignis. Aber bei WebSocket kann man parallel auf viele Ereignisse warten (z.B. Timer). Da wäre Event-orientiertes Programmierung sinnvoll. Und das sollte mit GUI nichts zu tun haben. Das es das doch hat, ist ein momentanes Manko von Lazarus. (MSE hat dieses Problem nicht, es geht also durchaus anders.)

-Michael

[Christian]

Die genannten Funktionen sind alle zur Synchronisation mit einer GUI gedacht. Von daher macht deine Aussage keinen Sinn.
Du brauchst wenn du nen Server Dienst schreibst keine GUI.

Wie kommst du darauf das sich Websockets anders verhalten als ein CGI sonst ? Irgendwie macht ein großer Teil deiner Aussagen keinen Sinn.

[mschnell]

Die genannten Funktionen sind alle zur Synchronisation mit einer GUI gedacht.

Unsinn (Thread-to-Mainthread Signalling ist beispielsweise bei der Arbeit mit seriellen und TCP/IP-Schnittstellen sehr hilfreich, um die diversen inputs in einem Thread (eben dem Mainthread) zusammenzuführen.) TThread.Queue und TThread.Synchronize sind auch nicht in der LCL, sondern in der fpc-RTL realisiert. Man kann sie also auch komplett ohne lcl oder eben mit einem (neu zu erstellenden) "aktiven" Widget-Type ohne lokale GUI Anbindung verwenden.
Hast Du noch nie embedded Applikationen gemacht, die unbeobachtet (also ohne GUI) vor sich hin laufen ? Die brauchen Timing, warten gleichzeitig auf jede Menge externe Events von irgendwelcher Hardware, auf serielle Schnittstellen, TCP/IP, ... (Meine Kollegen machen das mit Delphi auf Windows , u.a. weil genau das beschriebene mit Lazarus auf Linux nicht geht - und man mit mse nicht so leicht den bestehenden Delphi-Code verwenden kann. )

Du brauchst wenn du nen Server Dienst schreibst keine GUI.

Auch Unsinn
Stimmt für ein traditionelles CGI. Aber gerade WebSockets bietet dem Dienst ja die Möglichkeit, im Browser eine GUI zu zeigen.

Wie kommst du darauf das sich Websockets anders verhalten als ein CGI sonst ?

Müssen sie nicht, können sie aber (und das ist das was mich hier interessiert).
Wenn ein "Dienst" in der Lage ist, von sich aus Meldungen an den Browser abzusetzen (das ist ja der Sinn von Websocket und den diversen "Comet" Abkömmlingen), kann der Dienst eine längere Zeit autark diverse Sachen machen (u.a. auch auf irgendwelche Ereignisse reagieren, die nicht vom Browser aus initiiert werden). Ein klassisches CGI wird durch den HTTP-Server auf Veranlassung des Browsers gestartet, generiert irgendwelche anzuzeigenden Daten , gibt die an den HTTP-Server, der sie dann an den Browser weiterleitet. Ganz klassisch tut der Webserver das definitiv erst, wenn das CGI sich beendet hat (da gibt es aber Möglichkeiten). Bei FastCGI (und Apache-Modulen und ISAPI-DLLs) kann das CGI auch laufen, wenn nicht gerade ein Browser-Connekt offen ist. Comet hält den Bowser-Connect halb-legal offen, um spontane Meldungen (effizienter als mit Java-Polling) ausgeben zu können. Websocket bietet da anscheinend noch weitgehendere und vor allem "legale" Möglichkeiten. Mit FCGI und ISAPI ist es möglich, dass das "CGI" permanent läuft (also ein "embedded" Dienst ist), und erst dann mit einem Browser kommuniziert, wenn der einen Request an das CGI absetzt. Dadurch kann man einem embedded Progamm eine Web-basierte Oberfläche geben. Das ist bei in C programmierten Gadgets (Router, NAS, ..., aber auch bei "normalen" Dienste wie VMWare) inzwischen völlig üblich, scheint mir aber im Vergleich zu Lazarus-Programmierung ziemlich aufwändig zu bauen zu sein. Es wäre schön, wenn Lazarus dafür (optionale remote-GUI) eine Unterstützung "Out of the Box" bieten würde. (mse hat dafür zumindest gewisse Möglichkeiten. ) (Die genannten Beispiele haben meist einen eingebauten Webserver, aber auch Verwendung "hinter" einem Webserver ist bei Applikationen sinnvoll, die z.B. im Internet "veröffentlicht" werden sollen - wie die meiner Kollegen.)

-Michael

[Christian]

Hast Du noch nie embedded Applikationen gemacht, die unbeobachtet (also ohne GUI) vor sich hin laufen ?

Doch gehört zu meinem Job.
Da hat man meisst nichtmal die Möglichkeit Threads zu nutzen weil kein Betriebsystem da ist.
Ich arbeite dort aber selten mit Systemen die so riesig sind das da überhaupt nen TCP/IP Stack da ist.
Ich setll mir aber vor das man da im wesentlichen mit dem Main Thread synchronisiert um Ein/Ausgaben zu machen also art GUI.

Auch Unsinn
Stimmt für ein traditionelles CGI. Aber gerade WebSockets bietet dem Dienst ja die Möglichkeit, im Browser eine GUI zu zeigen.

Mhm, die GUI läuft aber komplett im Browser und nicht auf deinem Server. Soviel zum Unsinn. Und Websockets sind das selbe wie CGI, nur dad du nicht ständig Verbindungen auf und zu machst. Ich bin mittlerweile dabei das 3. große System auf dieser Basis zu erstellen, und deinen Antworten nach hast du noch nie damit zu tun gehabt.

[mschnell]

Da hat man meisst nichtmal die Möglichkeit Threads zu nutzen weil kein Betriebsystem da ist.

Genau das mache ich auch. Inzwischen ist es aber durch die Preis/Leistungs-Relation bei Prozessoren und den fallenden RAM-Preisen, der fast überall geforderten Kommunikation über TCP/IP und der Qualität von Linux mehr und mehr sinnvoll, ein embedded System auf einem ordentlichen Betriebssystem aufzubauen.

Mhm, die GUI läuft aber komplett im Browser und nicht auf deinem Server.

Das wäre dieselbe Aussage wie "Im PC läuft die komplette GUI auf der Grafik-Karte".

Ich bin mittlerweile dabei das 3. große System auf dieser Basis zu erstellen, und deinen Antworten nach hast du noch nie damit zu tun gehabt.

Deshalb diskutiere ich ja hier: um was dazuzulernen.

Dass die angesprochenen Aspekte für Dich noch nicht wichtig waren, heißt nicht, dass das für andere nicht anders ist.

Wie gesagt: schau Dir die Web-Oberfläche eines Routers oder NAS an: Ich würde so etwas gerne mit Lazarus machen und dabei den Lazarus-GUI Designer verwenden. Klar geht das nicht ohne Haken und Ösen, aber das Lazarus-Team ist ja auch dabei GUI-Oberflächen für Android und ähnliches zu ermöglichen. Es gibt z.B. bereits einiges, das in diese Richtung weist (z.B. "Custom Drawn" und "fpGUI").

Embedded System z.B.:
- BeagleBone Black (40 Euro fertig gekauft für den Prototyp, oder in der Serie etwas ähnliches für noch weniger auf einer eigenen Leiterplatte - dann kann die Grafik-Unbterstützung weggelassen werden).
- Linux
- WebServer (z.B. Apache)
- Embedded Funktionalität mit Lazarus programmiert
- Zur Konfiguration lggt sich der Benutzer mit einem Browser ein und Das Lazarus-Programm zeigt eine hübsche Web-GUI.

-Michael


-Michael

[m.fuchs]

Mhm, die GUI läuft aber komplett im Browser und nicht auf deinem Server.

Das wäre dieselbe Aussage wie "Im PC läuft die komplette GUI auf der Grafik-Karte".

Quark, die GUI läuft kein bisschen auf der Grafikkarte. Die Grafikkarte sendet Signale an den Monitor die Bilder darstellen. Die Karte weiß nix von Fenstern und Controls.

Die GUI in einer Webanwendung (sei es nun CGI oder Websockets oder sonstewas) ist nichts, was zu der entsprechenden Serveranwendung gehört. Es ist einfach ein Client-Server-System. Also ZWEI Anwendungen.

[mschnell]

Eben. "die GUI" - also das was pro User-Programm unterschiedlich ist - läuft auch nicht ernsthaft "Im Browser", sonden nur einzelne "Widgets". Typisches Beispiel: EXTJS: Das Java-Script ist immer gleich und erzeugt Widgets, das jeweilige CGI-Programm baut daraus seine individuelle GUI auf. (Mit eigener Java-Programmierung ist das natürlich skalierbar, wenn man das will.)

Die Grafik-Karte hat auch einen Prozessor, der eine ganze Menge macht.

Die "GUI" hat viele hierarchische Ebenen, die alle zusammen die "GUI" bilden. (User-Programm, Bibliothek (z.B. LCL), Widget-Set (z.B. QT), X, Grafik-Treiber, Grafik-Prozessor, Bildwiderhol-Speicher, ...)

Dazwischen gibt es überall Schnittstellen, an denen ein "Remoting" ansetzen kann.

X kann seit Urzeiten Remote (ganz früher sogar ausschließlich).

Eine WEB-GUI wäre ein entsprechendes Widget-Set (das natürlich in der Programm-Library entsprechende Unterstützung braucht, wie ja die lcl auch jeweils Code für QT, GTK, Carbon, Cocoa, Windows, ... eigenen Code, aber eine gemeinsame API zum User-Programm hat).

Wie gesagt, gibt es Unmengen (vermutlich meist in C realisierte) Beispiele für Web GUIs, die auf EXTJS und ähnlichen "Frameworks" aufbauen, die im Browser einzelne Widgets (aber nicht viel mehr) realisieren.

Dass Lazarus das (noch) nicht kann, liegt nur daran, dass sich da noch niemand drangegeben hat (das soll kein Vorwurf an irgendjemand sein, ich recherchiere nur die Möglichkeiten, wie sowas zu machen sein könnte).

-Michael

[Christian]

Michael, ich geb hier auf. Du scheinst einfach auf deinen Standpunkten zu beharren und nichts dazulernen zu wollen. Wenn man dir sagt ein Vergleich passt nicht informierst du dich nicht und stellst deine Thesen in Frage sondern behauptest den selben Quark einfach weiter. So macht das keinen Spass mit dir zu diskutieren. Von Wiederholungen werden Behauptungen nicht zu Tatsachen.

[mschnell]

Danke, gleichfalls !
Wir reden völlig anscheinend an einander vorbei: ich sage: " ' A ' könnte sinnvoll und möglich sein, wie könnte man das wohl machen ? " Und Du antwortest: "nein nein nein ' B ' geht nicht !"
Das bringt so nix.

-Michael

[mschnell]

Websockets sind HTTP Verbindungen die mit Upgrade zu ner Websocket Verbindung umgebaut werden somit gibts da keine Einschränkungen bezüglich Firewalls u.s.w.
Wie kommst du eigentlich darauf, die von dir verlinkte Wikipedia Seite erklärt das doch vernünftig ?!

Siehe den neuen Thread "FCGI MultiThreaded" in der fpc-pascal Mailing Liste.
Michael Van Canneyt klärt hier auf:

"The two technologies HTTP and websockets are unrelated. The websocket simply uses the HTTP headers as a start, but the rest of the protocol is completely different. "

-Michael

[Christian]

Something is wrong on the internet