Smart linking mal probieren.
---
Die Binaries stehen im Buffer vom Filesystem
---
Kurz mein Einwand.
So wie ich das sehe.
Fast CGI Executable -> 1:n Modules -> m:1 Commando Prozessor (Interpreter) Module *), letzteres wird (im Moment noch) statisch gelinked am Ende, soferen das Framework das die Website baut nochmal in eine SO kommt.
*) Im Sinne was alle deine Webpages verbindet, deswegen bin ich mit dem Ausdruck Interpreter ein wenig vorsichtig.
DB Sessions?
Session zum Datenaustausch allgemein?
Was wäre die logische Konsequenz selbst wenn kein weiteres Sessionsmanagment notwendig wäre. Die
HTML Datei bleibt extern und beinhaltet die Kommandos für den Kommandointerpreter
. Das läuft auf SSI raus und Rückzug des 'Commandointerpreters' in die Fast CGI Executable.
Der Vorteil deines Vorschlags liegt in der Glättung des Speicherbedars.
Was du machst gibt es wohl. Vorgenerieren von Webpages in Caches. Dann macht das Sinn. Weiters wäre der Vorteil, dass du die Sammlung der PHP Seiten nicht musst packen. Im schlimmsten Fall komprimierst du die Exe, was in der Regel nicht notwendig wäre.
Ich habe mir FAST-CGI eher im Umfeld von 'Services' angeschaut. Dort ist die Sinnhaftigkeit unbestritten.
Sobald du bspw. in die Gegend Embedded or geringer Speicher kommst, dann kommt schnell ein Schwenk in Richtung SSI.
Weil es mir um die modulare Idee geht. Natürlich könnte man das alles in eine Anwendung packen und den Server kurz neustarten, aber praktischer, und interessanter, wäre es doch, wenn man einfach, wie ein PHP-Skript, eine Datei ins Verzeichnis packte und die Ausgabe einfach über den Namen performant zu erreichen wäre.
Und eigentlich müsste das ja gehen. Da alle Bibliotheken größtenteils denselben Code verwenden (dieselben Units und Packages) müsste sich das doch eigentlich auslagern lassen, bis man nur noch wenige Kilobyte pro Datei hat...
Oder träume ich da nur?
