nicht angemeldet
Wenn schon durcheinander, dann richtig ;-)
Aber erstmal: Hallo,
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?)
Existiert auch auf Windows. Muß schon alleine deshalb, weil es einen guten Teil der Grundfunktionalität von MS-Produkten umfaßt.
(kann nie wiederstehen, wenn ich gutgelaunt bin ;-)
STDERR habe ich ausgelassen, da er für die CGI-Funktionalität nicht unbedingt notwendig ist.
STDERR ist manchmal die einzige Möglichkeit, etwas über den Zustand des Servers zu erfahren, so wie manche, für teures Geld angemietete Accounts, eingeschränkt sind. (Es grenzt ja schon mitunter an Betrug, was da abgeht: auf der einen Seite offen wie ein Scheunentor, auf der anderen Seite wird der User ohne Ende und vor allem Sinn und Verstand beschnitten. Wie in einem Posting weiter oben schön gezeigt, wo 1&1 einen Kunden, der seinen Transfer komplett bezahlt, nichts umsonst wollte, recht willkürlich rausschmeißt.)
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.
Na, ungeeignet nicht unbedingt, da sich die Darstellung der Elemente unterdrücken läßt. Ich selber habe schon mal eine Textfeld mißbraucht, da bei Tk der Inhalt eines solchen in einem Binary Tree gespeichert wird und deshalb sehr gut durchsuchbar ist. Aber gut, das war nicht für eine CGI-Anwendung und fällt auch eher unter die Rubrik "kreativer Umgang mit Technik" ;-)
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]
Aha, mal schauen, ob er Dir glaubt ;-)
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.
Geht ihn ja auch schließlich gaaar nix an! ;-)
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.
Ach, noch viel weniger. Das ist eigentlich nur eine Lib in der die gängigsten Methoden versammelt sind, die man sonst alle mühsam selber coden müßte.
Die Schnittstelle hat eigentlich gar kein Protokoll, da sie nur die Dateien STDIN, STDOUT und STDERR scharf schaltet und ein paar Environment Variablen belegt, auf das die Daten mit Begründung da durchpfeifen können.
"Ceci n'est pas un pipe"
Ja, ich weiß, 2 EUR in die Wortwitzkasse ;-)
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.
War das nicht einmal das ursprüngliche Ziel von TCL? >;->
so short
Christoph Zurnieden