nicht angemeldet
hi,
Da der Kollege Klaus Mock da etwas präziser war, möchte ich da auch nicht nachstehen. (Das Paket ncgi ist im Paket tcllibs. Aktuell scheint 1.3.0 zu sein: http://belnet.dl.sourceforge.net/sourceforge/tcllib/tcllib-1.3.tar.gz (1113 kb) braucht mindestens TCL 8.2.
Danke. Richtig, Klaus Mock ist ziemlich genau gewesen, ich versuch da auch noch eine Erwiderung, weil ich mich zwar korrekt, aber offenbar nicht präzise genug geäußert hatte.
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. _Das_ kann TCL (auch ohne Tk, bloß mit Tk siehts besser aus), vorausgesetzt, es ist auf dem Client installiert. Dazu ist nicht einmal die tcllib (die ich auf allen meinen Systemen zur Verfügung habe, danke für dein Angebot, sie zu schicken) zwingend nötig, man könnte sich mit etwas Arbeit eine entsprechende Bibliothek selber zusammenschrauben. Wie das prinzipiell geht, steht in "Practical Programming in Tcl and Tk" von Brent Welch (siehe http://www.beedub.com/book/), das ich auch in gedruckter Form habe. Und es gibt noch einige weitere auch online verfügbare manuals, siehe http://resource.tcl.tk/resource/doc/books/.
Alle diese klugen und teils sehr ausführlichen Darstellungen betreffen aber lediglich die "Auflösung" eines über CGI vermittelten Datenstroms auf einem Rechner, auf dem TCL installiert ist.
Bei der "CGI-Funktionalität" von PERL gibt es einen entscheidenden Unterschied: du kannst von Clientseite aus über ein CGI-Script den _Server_ veranlassen, die Scriptbefehle an den auf dem Server-Rechner installierten Interpreter weiterzureichen - der Apache macht das unter anderem, indem er die "script-alias"-Angaben befolgt. Der Client _braucht dazu nicht_ PERLL installiert zu haben. Der Interpreter auf dem Server-Rechner macht das, was im Script steht, und liefert das Ergebnis beispielsweise als generierten HTML-Code an den Server zurück, der das dann brav an den Client weiterreicht. Der Client braucht dazu bei PERL keinen installierten Interpreter. Und _dieser_ Mechanismus funktioniert nach meinen bisherigen Kenntnissen mit TCL nicht. Jedenfalls nicht _ohne installierten TCL-Interpreter_. Ist TCL sowohl auf dem Server wie auf dem Client installiert, geht es. Meine Frage, mein Problem, mein Hinweis (wie auch immer du es nennen möchtest) bezog sich einzig darauf, daß bei PERL die "CGI-Funktionalität" auch dann in vollem Umfang erreicht werden kann, wen _nur_ der Server-Rechner, aber _nicht_ der Clíent-Rechner über eine voll funktionsfähige und per %PATH% ansprechbare Installation verfügt. Willst du dieselbe "CGI-Funktionalität" mit TCL erreichen, muß auf beiden Rechnern (wenn denn Client und Server zwei physikalisch unterschiedliche Rechner sind) TCL installiert sein, und leider auch noch in der dem Script entsprechenden Version.
<schüchterne Anfrage>
hab ich mein "Problem" jetzt genauer beschrieben?
</schüchterne Anfrage>
mod_tcl http://tcl.apache.org/mod_tcl/mod_tcl.html und
mod_dtcl http://tcl.apache.org/mod_dtcl/ dürften Dich da auch interessieren.
Ja. Tun sie. Hab ich zwar auch schon mehrfach draufgekuckt, aber möglicherweise noch nicht in Gänze kapiert. Ziel der beiden Module ist (wenn ich sie richtig verstanden habe), für TCL-Scripts die Möglichkeit zu eröffnen, daß als "embedded Code" vermittelt werden können - ähnlich wie das mit dem interessanten Projekt EMBPERL auch für PERL-Code versucht wird. Aber _gerade_ diese Module setzen selbstverständlich voraus, daß der (Client-)Rechner, der solche HTML-Dokumente mit eingebettetem TCL entgegennimmt, die Interpretation des TCL-Codes an einen TCL-Interpreter weiterreichen kann. Damit hätten wir uns im Kreis gedreht.
Es gibt nichts, was man nicht ändern könnte ;-)
da stimme ich dir gerne zu, prinzipiell.
Vielleicht hab ich ja bisher immer nur nen Komma oder nen Semikolon übersehen, ist ja alles mit weitreichenden Folgen möglich.
Grüße aus Berlin
Christoph S.