nicht angemeldet
Hallo,
Ich hänge mich einfach hier an, und beantworte auch einige Sachen aus dem anderen Teilthread.
------------------------------------------
Was ist 'diese CGI-Funktionalität'? Meines Erachtens nur die Fähigkeiten auf STDIN,STDOUT und Environment zugreifen zu können. Und diese Fähigkeiten wird TCL sicherlich auch haben.
Hat es, und STDERR hast du jetzt nicht aufgezählt (weil das auf WINDOWS nicht existiert?)
STDERR habe ich ausgelassen, da er für die CGI-Funktionalität nicht unbedingt notwendig ist.
hihi ;-) das geht auf einem Windows-Rechner noch um eine Zeile kürzer:
button .hallo -text hallo \ -command {puts stdout "hallo welt!"}
pack .hallo -padx 20 -pady 10
Aber dann sind wir wieder bei TK und das wollen wir ja nicht, da es für CGI-Scripts ungeeignet ist.
------------------------------------------
Richtig im Zusammenhang "CGI und TCL" ist folgendes: Wenn der Server über die CGI-Schnittstelle irgendeinen Datenstrom an den Client schickt, muß auf Client-Seite "etwas" vorhanden sein, was diese Schnittstelle überhaupt versteht und den Datenstrom in eine menschenlesbare Darstellung umwandelt.
Die Schnittstelle zum Client heißt HTTP. Das einzige, was am Client laufen sollte, ist ein User-Agent, der HTTP versteht. Nichts anderes ist (vorerst) zusätzlich notwendig.[1]
CGI ist dem HTTP-Request nachgeschaltet und hat mit der eigentlichen HTTP-Anfrage nichts zu tun. Der HTTP-Client 'weiß' ja nicht einmal, _wie_ der Server seinen Request abarbeitet und ob er CGI überhaupt einsetzt.
Somit ist es die Sache des Webserveres, ob und wie er eine CGI-Anwendung startet. CGI ist eben nur ein Schnittstellenprotokoll zwischen Webserver und einer auf dem Server laufenden Anwendung.
Was muß den eine CGI-Anwendung können?
Sie muß aufgrund einer Environment-Variable entscheiden, ob die allfälligen CGI-Parameter aus dem Environment oder von STDIN gelesen werden sollen (GET oder POST).[2]
Sie muß in der Lage sein, diese Parameter analysieren zu können.
Sie muß in der Lage sein, aufgrund der internen Programmlogik, Informationen dem HTTP-Protokoll entsprechend per STDOUT ausgeben zu können. Dabei können die ermittlten Parameter zu Hilfe genommen werden, um die internen Abläufe zu steuern.
Und dafür kannst Du jede Sprache verwenden, so lange sie nur die von mir genannten Mindestvoraussetzungen erfüllt.
Das alles muß sie nur auf dem Server können.[3] Der HTTP-Client wird von all dem nichts mit bekommen.
TCL (ohne TK) ist also durchaus geeignet, für CGI-Anwendungen benutzt zu werden.
Und wenn TCL Netzwerkfähigkeiten hat, die es ermöglichen, verteilte Anwendungen zu schreiben, so ist das auch gut, genauso wie es schön ist, wenn man, unter Zuhilfenahme der TK-Erweiterungen, daß man damit auch GUI-Programme schrieben kann.
Nur ist beides für das aktuelle Problem nicht von Belang.
Grüße
Klaus
[1] Wenn die Daten, die dann per HTTP übertragen worden sind, dann auch noch interpretiert werden sollen, dann ist clientseitig natürlich zusätzliche Logik notwendig, un dies zu erledigen. Das hängt aber wiederum von der Art der Daten ab. In vielen Fällen wird es aber HTML sein, was ein halbwegs brauchbarer Browser ohne Fremdhilfe erledigen kann. Aber auch das ist IMHO nicht das Thema
[2] Wobei anzumerken ist, daß es auch durchaus andereArten von Requests gibt, welche eventuell andere Handlungsweisen bedingen.