nicht angemeldet
Inline-Module
guten Abend ;-)
In einem Thread weiter unten ([pref:t=48450&m=264540]) hat Henryk die Adresse http://nms-cgi.sourceforge.net/ empfohlen. Man bekommt dort (unter anderem) eine "aktualisierte" Fassung des wwwboard-Scripts von Matt Wright. Ich hatte mir das vor längerer Zeit schon mal angeschaut, war aber unschlüssig, aus folgendem Grund: Das Perl-Script ist ziemlich genau 2400 Zeilen lang und damit mehr als dreimal so umfangreich wie das "alte" - das zugestandenermaßen ein paar Sicherheitslöcher hat.
Jetzt habe ich es mir doch mal gründlicher angeschaut und dabei festgestellt, daß ziemlich genau zwei Drittel dieses neuen Scripts eigentlich "Inline-Module" sind, die man auch als eigenständige Module mit dem Namen *.pm wieder auslagern könnte.
Ich wußte zwar schon eine Weile, daß man sich eigene Module bei Bedarf erstellen kann und habe gelegentlich ganz erfolgreich damit herumexperimentiert, die Methode, solche Module aber gleich ins Perl-Script mit aufzunehmen, kannte ich aber noch nicht.
Meine Frage jetzt: wie sinnvoll ist es, sowas im Script zu belassen? Ich mag einfach Scripts mit über 1000 Zeilen nicht so besonders, es ist schwer, bei solchen Größenordnungen die Übersicht zu behalten, und außerdem habe ich ein paar schwer zu beweisende Bedenken, was die Performance betrifft. Sind solche Bedenken gerechtfertigt? Oder bringt es doch Vorteile, wenn man wirklich _alles_ in ein großes Script reinschreibt?
Mein Hauptbedenken gilt der Tatsache, daß das wwwboard schließlich eine cgi-Applikation ist und eigentlich so schnell als möglich seine Arbeitsergebnisse an den Server zurückliefern soll. Von verschiedenen LINUX-Installationen sind mir PERL-Scripts (oder/und Shell-Scripts) bekannt, die auf Systemebene arbeiten sollen und sogar noch deutlich umfangreicher sind als bloß ein paar lächerliche 2400 Zeilen - aber das sind dann eben keine cgi-Applikationen, die Dinger dürfen sich auch nen bissel Zeit lassen (man denke an die "configure"-Scripts zum Installieren von Software wie z.B. Apache).
Und noch eine Kleinigkeit: ich habe mir das Script natürlich schnell mal runtergeladen, in den Systempfaden (das sind lediglich drei Variablen) für mein aktuelles System modifiziert, um es ans Laufen zu bringen. Nur hab ich das auf einem WinXP-Rechner gemacht (der selbstverständlich sowohl einen ordentlichen Webserver wie auch ein aktuelles PERL hat), und das Script verlangt nun in Zeile 212 eine Angabe für
$basedir/.lock
buuhhhh! Wenn es keine solche Datei gibt, kriege ich nen Server-Error, aber wenn ich so eine Datei zu erstellen versuche, sagt mir mein WinXP, daß das nicht geht - "Sie müssen einen Dateinamen angeben". Will heißen, vor dem Punkt muß noch irgendwas stehen. Aus lauter Verzweiflung habe ich nach zwei Stunden einfach mal den Punkt weggelassen, und siehe da, das durfte ich dann plötzlich, und das Script akzeptierte meine null byte große "lock"-Datei sogar ohne weitere Nachfrage.
Die Punkte sind ja von ihrer Funktion her nur das Zeichen dafür, daß es sich um eine "versteckte" Systemdatei oder Konfigurationsdatei handelt, in die zur Laufzeit bzw. bei Bedarf etwas hineingeschrieben werden kann oder aus der wesentliche Informationen zum Verhalten entnommen werden können. Warum erlaubt mir WinXP nicht, so eine ".lock" anzulegen, wenn das doch mit ".htaccess" problemlos funktioniert?
Grüße aus Berlin\n\nChristoph S.
-
hi ;-)
kurzer Nachsatz: wie kam das jetzt zustande, daß untendran
Grüße aus Berlin\n\nChristoph S.
gestanden hat? Das hab ich in meinen "my"-Einstellungen so vorgegeben, aber die Ummbrüche sollten doch "hidden" sein und nicht dargestellt werden. Bastelt CK grade wieder am Code?
Grüße aus Berlin
Christoph S.
-
Hi!
Meine Frage jetzt: wie sinnvoll ist es, sowas im Script zu belassen? Ich mag einfach Scripts mit über 1000 Zeilen nicht so besonders, es ist schwer, bei solchen Größenordnungen die Übersicht zu behalten, und außerdem habe ich ein paar schwer zu beweisende Bedenken, was die Performance betrifft. Sind solche Bedenken gerechtfertigt? Oder bringt es doch Vorteile, wenn man wirklich _alles_ in ein großes Script reinschreibt?
Ich weiß nicht wie genau die PERL Module eingebunden werden, aber wieso sollten externe Module schneller sein als interne? Ich würde eigentlich genau umgekehrt denken ;-)
Und ich bastle gerade an einer PHP-Anwendung, die auch mit einer CGI-Version läuft. Da binde ich sicherlich über 10.000 Zeilen Code ein(PEAR, Smarty, eigene Module...), und das Parsen und Einbinden ist so viel schneller als ich gedacht habe, darum mache ich mir eigentlich nicht viele Sorgen.
Die Punkte sind ja von ihrer Funktion her nur das Zeichen dafür, daß es sich um eine "versteckte" Systemdatei oder Konfigurationsdatei handelt, in die zur Laufzeit bzw. bei Bedarf etwas hineingeschrieben werden kann oder aus der wesentliche Informationen zum Verhalten entnommen werden können. Warum erlaubt mir WinXP nicht, so eine ".lock" anzulegen, wenn das doch mit ".htaccess" problemlos funktioniert?
Wie hast Du das denn probiert? Ich mache sowas zur Not immer mit Proton von Ulli Meybohm (http://www.meybohm.de/proton.html), der legt zumindest unter win2000 alles an was ich will.
Viele Grüße
Andreas-
hallo Andreas,
Ich weiß nicht wie genau die PERL Module eingebunden werden, aber wieso sollten externe Module schneller sein als interne? Ich würde eigentlich genau umgekehrt denken ;-)
Mag ja sein, daß ich da "verkehrt herum" denke, deshalb frage ich ja.
Warum erlaubt mir WinXP nicht, so eine ".lock" anzulegen, wenn das doch mit ".htaccess" problemlos funktioniert?
Wie hast Du das denn probiert? Ich mache sowas zur Not immer mit Proton von Ulli Meybohm (http://www.meybohm.de/proton.html), der legt zumindest unter win2000 alles an was ich will.Proton habe ich zur Zeit nicht installiert. Mein "Standardeditor" ist TextPad, und der hat bisher auch alles gemacht, was ich wollte. Es scheint irgendwie an dem Namen ".lock" zu liegen.
Ich habe mir jetzt so geholfen, daß ich einfach auf FreeBSD umgeschaltet habe - das hat Zugriff auf dieselben Partitionen und kann natürlich Dateien (auch leere) mit solchen Namen anlegen.
Grüße aus Berlin
Christoph S.
-
Hi Christoph!
Ich weiß nicht wie genau die PERL Module eingebunden werden, aber wieso sollten externe Module schneller sein als interne? Ich würde eigentlich genau umgekehrt denken ;-)
Mag ja sein, daß ich da "verkehrt herum" denke, deshalb frage ich ja.Ich denke mir nur, der Code der geparst ist ist derselbe, nur spart man sich das Einbinden, wobei das ganze mit irgendwelchen Caching-Mechanismen natürlich auch anders aussehen kann, ich weiß es nicht, vielleicht kannst Du es ja messen.
Warum erlaubt mir WinXP nicht, so eine ".lock" anzulegen, wenn das doch mit ".htaccess" problemlos funktioniert?
Proton von Ulli Meybohm (http://www.meybohm.de/proton.html)
Proton habe ich zur Zeit nicht installiert. Mein "Standardeditor" ist TextPad, und der hat bisher auch alles gemacht, was ich wollte. Es scheint irgendwie an dem Namen ".lock" zu liegen.Hm, unter Win2000 geht es mit Proton. Proton musst Du überigens nicht großartig installieren, das ist nur ne .exe die Du direkt ausführen kannst. Ich arbeite sehr gerne mit Proton, eben weil der noch nie mit solchen Sachen Probleme gemacht hat...
Aber vielleicht liegt es auch an WinXP dass das irgendwie nicht geht.Ich habe mir jetzt so geholfen, daß ich einfach auf FreeBSD umgeschaltet habe - das hat Zugriff auf dieselben Partitionen und kann natürlich Dateien (auch leere) mit solchen Namen anlegen.
Naja, auch ein Weg ;-)
Viele Grüße
Andreas
-
-
-
Halihallo Christoph
Dass du immer so lange Posts verfassen musst :-)
Jetzt habe ich es mir doch mal gründlicher angeschaut und dabei festgestellt, daß ziemlich genau zwei Drittel dieses neuen Scripts eigentlich "Inline-Module" sind, die man auch als eigenständige Module mit dem Namen *.pm wieder auslagern könnte.
Ich wußte zwar schon eine Weile, daß man sich eigene Module bei Bedarf erstellen kann und habe gelegentlich ganz erfolgreich damit herumexperimentiert, die Methode, solche Module aber gleich ins Perl-Script mit aufzunehmen, kannte ich aber noch nicht.Naja, hier verhält sich Perl so, als würde use die Quelltexte einfach zusammenpappen.
Warum also nicht gleich alles in einem Script?Meine Frage jetzt: wie sinnvoll ist es, sowas im Script zu belassen? Ich mag einfach Scripts mit über 1000 Zeilen nicht so besonders, es ist schwer, bei solchen Größenordnungen die Übersicht zu behalten, und außerdem habe ich ein paar schwer zu beweisende Bedenken, was die Performance betrifft. Sind solche Bedenken gerechtfertigt? Oder bringt es doch Vorteile, wenn man wirklich _alles_ in ein großes Script reinschreibt?
Nun, das ist davon abhängig, ob wirklich alle Module auch immer gebraucht werden. Wenn
dem so ist, ist es Performancetechnisch besser, alles in eine Datei zu packen,
andernfalls nicht unbedingt (der Parser muss nicht ellenlange Quelltexte parsen, deren
Code nie verwendet wird). Hinzu komme jedoch, dass beim Aufsplitten in mehrere Dateien
mehrere Zugriffe auf das Filesystem gebraucht werden, was wieder gegen die Lösung mit
Aufsplitten spricht... Es kommt wie gesagt etwas darauf an.Wegen Performance würde ich mir nicht umbedingt sorgen machen, es ist kaum spürbar.
Ich halte den menschlichen Aspekt für wesentlich wichtiger. Hat schonmal einer versucht
XML::DOM anzupassen? - Nunja, es ist wirklich etwas übel, durch mehrseitige Quelltexte
nach der gesuchten Methode zu forsten... Nun gut, bei 2400 LOC würde ich mir noch keine
grossen Sorgen machen, obwohl XML::DOM hat ja auch "nur" 5100.Das "All-In-One"-Konzept, wenn ich das so sagen darf, hat IMHO einen anderen Ursprung:
Nehmen wir als Beispiel XML::DOM, dort sind auch alle Module in eine Datei gepackt.
Das hat nicht unbedingt mit Performance zu tun, sondern es ist eine "exakte Abbildung"
einer Komponente. Eine Komponente ist eine Sammlung von Klassen und Schnittstellen,
die einem "Zweck" dienen; eine Komponente wird in einer Datei gespeichert (muss nicht,
aber es macht doch irgendwie Sinn). Es gibt IMHO auch eine Art "konzeptionelle
Begründung, warum man verschiedene Module nicht separat speichert, sondern zu Modul-
komplexen (Components) zusammenführt".Viele Grüsse
Philipp
--
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.