Wer benutzt noch CGI?

• +74 replies

• Taulmarill

  2009-09-02 17:10

  User since 2004-02-19 1603 articles

  Auch wenn ich selbst CGI (die Schnittstelle, nicht das Modul) als nicht mehr Zeitgemäß betrachte, war meine Wahrnehmung bisher, dass es noch stark verwendet wird, Habe aber mittlerweile das Bedürfnis, diese zu überprüfen. Wer benutzt hier noch klassische CGI-Scripte ohne FastCGI oder mod_perl im großen Stil und warum? $_=unpack"B*",~pack"H*",$_ and y&1|0& |#&&print"$_\n"for@.=qw BFA2F7C39139F45F78 0A28104594444504400 0A2F107D54447DE7800 0A2110453444450500 73CF1045138445F4800 0 F3EF2044E3D17DE 8A08A0451412411 F3CF207DF41C79E 820A20451412414 83E93C4513D17D2B

  • 	pq	2009-09-02 17:12

    User since 2003-08-04 8352 articles

    das kommt ganz darauf an, es gibt viele gelegenheiten, bei denen ein simples cgi-skript völlig ausreicht und seinen dienst tut =) battie z.b. ist sowohl für CGI als auch FCGI und mod_perl bereit (wobei CGI sehr langsam sein dürfte) Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices" lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem

  • +6 replies

  • 	GwenDragon	2009-09-02 17:18

    User since 2005-01-17 6226 articles	Solange mod_perl kein ausgeklügeltes System der Trennung de Zugriffsrechte der verschiedenen Webuser bei Multihosting hat, muss ich auch CGI verwenden; das läuft wenigstens sicher unter suexec.

    • 	sid burn	2009-09-03 21:00

      User since 2006-03-29 1520 articles	Und warum kein FastCGI? Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

    • +4 replies

    • 	guest Rolf Schaufelberger	2010-02-08 17:16

      	2009-09-02T15:18:38 GwenDragon Solange mod_perl kein ausgeklügeltes System der Trennung de Zugriffsrechte der verschiedenen Webuser bei Multihosting hat, muss ich auch CGI verwenden; das läuft wenigstens sicher unter suexec. Siehe http://perl.apache.org/docs/2.0/user/config/config... Du kannst damit jedem vhost einen eigenen perl-Interpreter geben.

      • +2 replies

      • 	sid burn	2010-02-08 17:30

        User since 2006-03-29 1520 articles

        Es ging aber eher um die Zugrifssrechte, wohl auf Dateiebene. Zwar kannst du unterschiedliche Interpreter wohl starten aber nicht jeder Interpreter läuft mit seinen eigenen Nutzerrechten. Sprich auch weiterhin laufen alle mod_perl Instanzen mit dem Nutzer/Gruppen Rechten vom Apache. Bei CGI, kann man aber jedes Verzeichnis mit seinen eigenen Zugriffsrechten erlauben, so das gerade im Shared Hosting Bereich benutzer "rolf" nicht auf die dateien vom "berger" zugreifen kann. Ich hatte aber auch gefragt warum dann nicht FastCGI? Da dies dort funktioniert. Aber bekam nie eine antwort. ;) Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

        • 	GwenDragon	2010-02-08 17:42

          User since 2005-01-17 6226 articles	Sorry, ich hatte das völlig vergessen, dir darauf zu antworten. Nachdem ich aber weiter unten schon mal was zur Verwendung von FastCGI schrieb, siehst du dass ich FastCGI nicht abgeneigt bin. ;)

      • 	pq	2010-02-08 18:24

        User since 2003-08-04 8352 articles

        ah, cool, das ist ja immerhin schonmal etwas. das könnte zum beispiel mein problem lösen, dass mehrere instanzen meiner app (z.b. battie) in dasselbe errorlog schreiben, obwohl jeder vhost sein eigenes errorlog hat. wenn die interpreter wirklich geteilt sind, sollte auch alles im jeweils richtigen errorlog landen. allerdings hat man dann evtl. den nachteil, dass mehr perl-instanzen laufen müssen, um die gleiche performance zu bekommen, da der interpreter-pool eben nicht mehr geteilt werden kann. und das mit den zugriffsrechten ist dann immer noch nicht gelöst, wie sid burn schon schrieb. Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices" lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem

  • 	murphy	2009-09-02 17:21

    User since 2004-07-19 1307 articles

    Persistente Webanwendungen mit FastCGI, SCGI, mod_perl oder sonst einer Technik haben, so finde ich, vor allem Vorteile für etwas größere Webanwendungen in denen ein Benutzer länger herumnavigiert. Man kauft sich aber auch zusätzliche Komplexität und Problemquellen ein. Für eine Reihe simpler Aufgaben finde ich die CGI-Schnittstelle völlig ausreichend. When C++ is your hammer, every problem looks like your thumb.

  • 	guest Coder	2009-09-02 17:22
    Subtree with 22 replies: Zeitgemäß vs. Performance

    Bin der Ansicht, dass man Dinge, die lange Jahre gute Dienste geleistet haben nicht einfach abschaffen/ersetzen sollte, weil man sie nicht mehr für "zeitgemäß" hält. Auch Frames, iframes etc. sind bis heute noch wunderbare Gestaltungsmöglichkeiten. Was treibt Euch an, Euch stets im Hintertreffen zu fühlen, wenn Ihr mal eine Methode oder einen Befehl anwendet, der älter 36 Monate ist? Warum wird heutzutage nur noch modebewußt gescriptet, anstatt bedarfsorientiert? mod-edit pq: teilbaum ausgelagert Last edited: 2010-03-08 20:33:15 +01:00

  • 	GwenDragon	2009-09-02 17:37

    User since 2005-01-17 6226 articles	mod_perllite wäre schön. Aber was meinst du mit zeitgemäß? Zeitgemäß wäre allgemein gemeint, mod_php5. :P

  • 	neniro	2009-09-02 18:26

    User since 2008-12-14 79 articles

    2009-09-02T15:10:55 Taulmarill Wer benutzt hier noch klassische CGI-Scripte (...) im großen Stil und warum? Ich mag CGI. Da meine Applikationen nie mehr als - wahrscheinlich - einige dutzend Nutzer haben/hatten war das performance-mäßig auch egal. Ansonsten vermute ich, dass es halt eine Gewohnheit ist. CGI.pm mag inhaltlich überladen sein, aber es ist auch sehr zuverläßig. Einzig die Verwendung von tied-Hashes hat mich mal in Schwierigkeiten gebracht. -- yet another amateur perl hacker

  • 	renee	2009-09-02 18:32

    User since 2003-08-04 13309 articles

    Ich würde lieber häufiger mod_perl (oder noch besser mod_perlite) nehmen, da ich aber viel entwickel, dass auch bei Shared Webhosting läuft, ist das nicht immer möglich. Mich stört vor allem die fehlende Persistenz bei "normalem" CGI. Wenn man DBIx::Class und Moose einsetzen will, ist das mit CGI nicht wirklich spaßig... $foo - Perl-Magazin (http://foo-magazin.de/) Perl-Nachrichten (http://perl-nachrichten.de/) -- http://renee-baecker.de/

  • +20 replies

  • 	sid burn	2009-09-02 18:42

    User since 2006-03-29 1520 articles

    Irgendwie fehlt für mich das mittelding zur Auswahl. "CGI ist in manchen Dingen brauchbar". Ich finde CGI weder Super, noch werde ich dazu gezwungen, allerdiengs mag es in manchen kleinen Fällen immer noch brauchbar sein. Eine Beispielaplikation ist z.B. Nagios die noch vollständig auf CGI basiert (also das Protokoll). Allerdiengs schaut auf so eine Monitoring Software auch keine hunderte Leute gleichzeitig drauf das es da groß zu Performance Problemen kommt. Und letztendlich ist es auch egal ob ein Seitenaufruf 10ms oder 1 sekunde dauert. Ansonsten kommt dieser Thread ja jetzt auch eher durch die Diskussion in diesem Thread: http://www.perl-community.de/bat/poard/thread/1396... Ansonsten ist dort nicht meine Aussage das CGI komplett nutzlos ist, sondern das es etliche Nachteile hat, und wenn diese nachteile wichtig werden eben die Lösung ist FastCGI oder mod_perl einzusetzen. Ansonsten stellt auch eine Entwicklung direkt für FastCGI z.B. kein besonderes problem dar. WebFrameworks abstrahieren es. Speziell für den Fall auf CGI optimiert z.B. CGI::Application so das wenn Performance ein Problem wird man von CGI einfach auf FastCGI switchen kann. Catalyst oder Jifty machen natürlich kein Sinn mehr unter CGI, auch wenn es angeboten wird. Aber solche Sachen sind auch so groß das man es wohl auch unter CGI nicht mehr besonders schnell bekommt und CGI hier einfach an seine grenzen stößt. Ansonsten für größere Sachen die man anfängt halte ich nichts mehr davon es noch auf CGI hin zu Optimieren. Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

    • +19 replies

    • 	Taulmarill	2009-09-02 19:06

      User since 2004-02-19 1603 articles

      2009-09-02T16:42:53 sid burn Ansonsten kommt dieser Thread ja jetzt auch eher durch die Diskussion in diesem Thread: http://www.perl-community.de/bat/poard/thread/1396... Ah Mist, du hast meinen Masterplan verraten :-) 2009-09-02T16:42:53 sid burn Ansonsten ist dort nicht meine Aussage das CGI komplett nutzlos ist, sondern das es etliche Nachteile hat, und wenn diese nachteile wichtig werden eben die Lösung ist FastCGI oder mod_perl einzusetzen. Ansonsten stellt auch eine Entwicklung direkt für FastCGI z.B. kein besonderes problem dar. WebFrameworks abstrahieren es. Speziell für den Fall auf CGI optimiert z.B. CGI::Application so das wenn Performance ein Problem wird man von CGI einfach auf FastCGI switchen kann. Catalyst oder Jifty machen natürlich kein Sinn mehr unter CGI, auch wenn es angeboten wird. Aber solche Sachen sind auch so groß das man es wohl auch unter CGI nicht mehr besonders schnell bekommt und CGI hier einfach an seine grenzen stößt. Sehe ich genau so. 2009-09-02T16:42:53 sid burn Ansonsten für größere Sachen die man anfängt halte ich nichts mehr davon es noch auf CGI hin zu Optimieren. Genau hier ringe ich ein bisschen mit mir. Auf der einen Seite ist es natürlich viel bequemer eines der großen Frameworks für umfangreiche Projekte zu benutzen. Andererseits hätte es seinen Charme, wenn ein größeres, attraktives Perl-Projekt ohne weitere Schwierigkeiten auf jedem Shared Webhoster zum laufen zu bringe währe. Mojo fällt mir da ein. $_=unpack"B*",~pack"H*",$_ and y&1|0& |#&&print"$_\n"for@.=qw BFA2F7C39139F45F78 0A28104594444504400 0A2F107D54447DE7800 0A2110453444450500 73CF1045138445F4800 0 F3EF2044E3D17DE 8A08A0451412411 F3CF207DF41C79E 820A20451412414 83E93C4513D17D2B

      • +18 replies

      • 	sid burn	2009-09-02 19:22

        User since 2006-03-29 1520 articles

        2009-09-02T17:06:45 Taulmarill Genau hier ringe ich ein bisschen mit mir. Auf der einen Seite ist es natürlich viel bequemer eines der großen Frameworks für umfangreiche Projekte zu benutzen. Nicht nur das. Da CGI ja ständig neu lädt muss man auch die Nutzung von manchen Modulen abwägen. z.B. DBIx::Class oder Moose. Und auf solche Module zu verzichten tut mir schon irgendwie weh. Das gleiche gilt generell für Module. Je mehr Module man nutzt umso länger wird die Ladezeit. Dann nutzt man noch Template::Toolkit, XML Module etc. und schwup ist man bei einer Ladezeit von einer Sekunde. Wenn man eine große Seite plant mit vielen nutzern ist das schon ziemlich ein K.O Kriterium. Wenn ich dann auf CGI achte heißt es für mich solche Module nicht mehr zu nutzen. Es evtl. Quick & Dirty zu machen, unsauber zu programmieren. Und alles nur weil CGI eben nicht Persistent ist? Sowas kann ich ich mit mir nicht mehr vereinen. ;) FastCGI hat diese Probleme nicht. Es ist auch nicht wirklich ein Problem der Module das sie beim starten lange brauchen, sondern eher ein Problem von CGI das es bei jeder Anfrage es ständig neu lädt. Von daher hat CGI sicherlich immer noch seine berechtigung für kleine Sachen, aber möchte man Modern programmieren und macht größere Sachen kommt man um solche Techniken einfach nicht mehr drum herum. Quote Andererseits hätte es seinen Charme, wenn ein größeres, attraktives Perl-Projekt ohne weitere Schwierigkeiten auf jedem Shared Webhoster zum laufen zu bringe währe. Mojo fällt mir da ein. Letztendlich kannst du jedes PurePerl Modul wie Mojo einfach bei einem Shared Hoster hochladen und nutzen. Aber auch wenn Mojo oder Sri sagt einfach hochladen und geht auch bei Shared hostern ist das naja auch etwas Marketing blabla. Was Perl ausmacht sind seine Module. Und Mojo ist auch ohne DBI, XML Prozessing, DateTime und die vielen anderen Module nicht wirklich viel Wert. Zu einem "einfach nur hochladen" endet das also auch nicht, auser man schreibt alle externen Bibliotheken selber. Ich kreide hier nicht Mojo an, sicherlich mag es nett sein, und ich wollte es mir auch irgendwann mal genauer anschauen, wenn die Doku ausgebaut ist, aber das es einfach nur "hochladen" ist und praktisch alles anbietet, naja dazu bietet es zu wenig. Und nutze ich eben andere Module entsteht als Endresultat das gleiche als wenn ich Catalyst nutze. Für eine große Anwendung ist also Mojo nicht Portabler als es Catalyst ist. Auser man entscheidet sich natürlich gar keine externen Module zu nutzen. Nichtmal DBI und speichert seine Daten in CSV Dateien. Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

        • +17 replies

        • 	GwenDragon	2010-02-03 14:22

          User since 2005-01-17 6226 articles

          2009-09-02T17:22:53 sid burn Da CGI ja ständig neu lädt muss man auch die Nutzung von manchen Modulen abwägen. (…) Je mehr Module man nutzt umso länger wird die Ladezeit. Dann nutzt man noch Template::Toolkit, XML Module etc. und schwup ist man bei einer Ladezeit von einer Sekunde. Korrekt, da hat zum Beispiel dann ein Skript mit 12 Modulen eine Ladezeit von 300 msec, während der Ablauf nur 30 ms braucht. Ein Blick mit NYTProf fördert dann zutage, dass diverse Modul…::BEGIN-Abschnitte die meiste Inklusivzeit verbrauchen. Dass bei Ladzeeiten von 300 – 500 ms und mehr nicht viele Requests auf das Skript laufen können ist klar. Abhilfe ist dann nur noch FastCGI oder mod_perl. mod_perl hat nur den Nachteil, dass alle Skripte in einer Multi-Host-Umgebung die Zugriffsrechte des Servers erben.[1] Skripte können dann eben auf Verzeichnisse anderer Domains zugreifen. Ein Sicherheitsmangel, den mod_perl immer noch nicht behoben hat.[2] Eine Abschottung wie mit su_exec über GUID/UID oder bei PHP mit safe_mode ist nicht möglich. //EDIT: Link korrigiert Last edited: 2010-02-03 14:24:49 +01:00

          • +16 replies

          • 	pq	2010-02-03 14:31

            User since 2003-08-04 8352 articles

            2010-02-03T13:22:50 GwenDragon Skripte können dann eben auf Verzeichnisse anderer Domains zugreifen. Ein Sicherheitsmangel, den mod_perl immer noch nicht behoben hat. ganz zu schweigen davon, dass man auch zugriff auf alle verwendeten packages hat und somit globale variablen und subs überschreiben kann. mod_perl ist toll, aber nur, wenn man den webserver für sich hat =) Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices" lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem

            • +15 replies

            • 	GwenDragon	2010-02-03 14:46

              User since 2005-01-17 6226 articles	Ja. Aber wo ist das schon. Manches ist auch Multihosting. Deswegen kann ich für Kunden kein mod_perl nehmen. =:(

              • +14 replies

              • 	sid burn	2010-02-03 14:47

                User since 2006-03-29 1520 articles	Du könntest aber FastCGI nehmen. Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

                • 	bianca	2010-02-03 14:58
                  Subtree with 13 replies: Fragen zu FastCGI

                  User since 2009-09-13 1812 articles	2010-02-03T13:47:53 sid burn Du könntest aber FastCGI nehmen. Das finde ich zunehmend interessanter, je öfter davon geschrieben wird. Gibt es dazu irgendwo eine deutsche Summary zu den Features, Voraussetzungen etc.? Danke mod-edit pq: teilbaum ausgelagert Last edited: 2010-03-07 02:20:29 +01:00 10 print "Hallo" 20 goto 10

  • 	LanX-	2009-09-02 23:03

    User since 2008-07-15 997 articles

    Die Frage ist für mich schwer zu beantworten, weil ich drauf achte dass sowohl CGI als auch FCGI geht (was sehr simple geht) Im Einsatz bevorzuge ich FCGI, habe aber so maximale Flexibilität bei der Serverwahl. IMHO wäre ne Trennung zu mod-perl angebracht gewesen. Ich hatte noch keinen Bedarf mit dem Server tiefer zu interagieren, deswegen mach ich mir da keine Gedanken. KISS halt. me and my writeups

  • +10 replies

  • 	MartinR	2009-09-03 08:33

    User since 2004-06-17 279 articles	2009-09-02T15:10:55 Taulmarill Wer benutzt hier noch klassische CGI-Scripte ohne FastCGI oder mod_perl im großen Stil und warum? Was gibt es denn für Alternativen bei den Shared Hosting Webspaces für 2,99 € ? Fotografie: Martin Rösl www.roesl-online.de

    • +9 replies

    • 	sid burn	2009-09-03 09:47

      User since 2006-03-29 1520 articles	PHP Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

      • +8 replies

      • 	MartinR	2009-09-03 10:32

        User since 2004-06-17 279 articles	Aber PHP läuft meines Wissens nach dort auch "nur" als cgi. Passt finde ich auch zu diesem Thread Perl Marketing Fotografie: Martin Rösl www.roesl-online.de

        • +2 replies

        • 	sid burn	2009-09-03 11:02

          User since 2006-03-29 1520 articles

          2009-09-03T08:32:16 MartinR Aber PHP läuft meines Wissens nach dort auch "nur" als cgi. In der Regel läuft PHP unter mod_php was etwas besser als CGI ist. Quote Passt finde ich auch zu diesem Thread Perl Marketing Finde ich nicht. Du bekommst halt das was du bereit bist auszugeben. Wenn du nur 3€ im Monat bereit bist auszugeben erwarte ich nicht das du einen komplett gewarteten Server, mit hoher Performance, am besten noch SSH Zugriff bekommst, und dann dort Module installieren kannst nach belieben + Persistente prozesse starten kannst. Für 3€ erwarte ich ein billiges zusammengeschnürtes System wo tausende benutzer drauf sind, der Server ständig ausgelastet ist und wo keinerlei persönliche bedürfnisse erfüllt werden, sondern es einfach nur ein massenmarkt ist. PHP ist für solche Anforderungen anscheind optimal geschnürt. Wer etwas Qualitat erwartet dem würde ich nichtmal ein 3€ Shared Hoster empfehlen selbst wenn er in PHP Codet. EDIT2: Irgendwie erwartet hier jeder das Essen aus einem 5.Sterne Restaurant zu bekommen für 1€ bei McDonalds. EDIT: Text des 3.blockes überarbeitet. Last edited: 2009-09-03 11:07:26 +02:00 Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

          • 	guest MartinR	2009-09-05 15:43

            Mit dem Preis/Leistungsverhältnis gebe ich Dir schon vollkommen recht. Nur ich will keine zig Euros pro Monat für einen eigenen Server ausgeben wenn es ein billiger - meine Zugriffe kannst Du an einer Hand abzählen - auch tut. Dafür hab ich mir lieber eine Fotoausrüstung im Gegenwert eines Kleinwagens zugelegt ... Meinen Verweis auf "Perl Makreting" hast Du aber fast selbst beantwortet mit "... PHP ist für solche Anforderungen anscheind optimal geschnürt ..." Wenn das ein Hobbyprogrammierer wie ich liest, ist doch die Entscheidung ob Perl eingesetzt werden soll schon gefallen, oder? ... nur um mitzuteilen woher ich die Weisheit habe. Der bekannte Hoster aus Montabaur schreibt in seinen FAQ PHP läuft bei 1&1 WebHosting als CGI.

        • +5 replies

        • 	GwenDragon	2009-09-03 13:38

          User since 2005-01-17 6226 articles	PHP als CGI? PHP läuft immer als mod_php, insbesondere oft im php_safe-Mode. Es sei denn du hast zwei Versionen wie 4 und 5 nebeneinander. Dann ist eines bestimmt als CGI laufend, weil beide nicht als Apache-Module nebeneiander laufen können – ich wüsste jedenfalls nicht wie. Aber da viele Hoster mittlerweile PHP5 fahren, ist die Betrachtung auch eher nicht mehr aktuell.

          • +3 replies

          • 	pq	2009-09-03 13:40

            User since 2003-08-04 8352 articles	aber php kann doch auch als mod_cgi oder mod_fcgid oder mod_fastcgi laufen, soweit ich weiss... Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices" lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem

            • +2 replies

            • 	GwenDragon	2009-09-03 13:52

              User since 2005-01-17 6226 articles	EDIT: Ähhhm, immer war auch blöd ausgedrückt. Sorry. Natürlich kann PHP auch unter mod_cgi oder mod_fcgi laufen. Aber bei Hostern, die ich kannte, wird das oft nicht gemacht. Auch bei vielen VServer-Paketen ist php gleich als mod_php + SafeMode drin.

              • 	pq	2009-09-03 13:56

                User since 2003-08-04 8352 articles

                ich dachte nur, weil du sagtest, es läuft immer als mod_php. ich hatte das hier dazu gefunden: http://www.majordojo.com/2007/11/is-mod-php-fallin... "PHP can be run using fastcgi (which he mentions as gaining popularity) [...]" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices" lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem

          • 	sid burn	2009-09-03 14:16

            User since 2006-03-29 1520 articles

            2009-09-03T11:38:18 GwenDragon Dann ist eines bestimmt als CGI laufend, weil beide nicht als Apache-Module nebeneiander laufen können – ich wüsste jedenfalls nicht wie. Bei mod_php würde ich erwarten das PHP1-5 alles in einer Binarie ist. ;) Ansonsten unter Debian Lenny zumindest heißt das Modul "php5" zum Laden, ich sehe zumindest kein grund warum nicht auch ein "php4" geben könnte. Ich meine zumindest bei Etch gab es beides Parallel? Oder bei Sarge? Dann gab es halt das mapping das endung mit ".php" an php5 weiter geleitet werden und um direkt php4 zu nutzen musste man ".php4" als endung nutzen. Naja weiß es auch nicht mehr genau. Nutze ja auch kein PHP. EDIT: 2ter Satz.Letztes Wort "sollte" -> "könnte". Last edited: 2009-09-03 14:19:04 +02:00 Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

  • 	lichtkind	2009-09-03 14:38

    User since 2004-03-22 3827 articles	wills jetzt für was kleines eignes verwenden und bräuchte daher auch noch zusätzlichen knopf für einen "mittelweg" WxPerl,Tafel,Perl 6,Tafeln kephra, baumhaus, garten Licht und Liebe ist alles was wir in Wirklichkeit suchen.

  • +5 replies

  • 	topeg	2009-09-03 15:04

    User since 2006-07-10 1298 articles	Ich nutze gerne den tinyhttp-Deamon, für 98% aller Inhouse-Lösungen ist er völlig ausreichend. Aber er unterstützt nur die CGI-Schnittstelle. Da für mich die Vorteile überwiegen, nehme ich das gerne auf mich. :-)

    • +4 replies

    • 	murphy	2009-09-03 17:55

      User since 2004-07-19 1307 articles	Ein ressourcensparender HTTP-Server, der aber auch FastCGI kann, wäre zum Beispiel noch Lighttpd When C++ is your hammer, every problem looks like your thumb.

      • 	sid burn	2009-09-03 18:18

        User since 2006-03-29 1520 articles	Oder "nginx". http://nginx.net/ http://wiki.nginx.org/Main Last edited: 2009-09-03 18:20:16 +02:00 Nicht mehr aktiv. Bei Kontakt: ICQ: 404181669 E-Mail: perl@david-raab.de

      • 	topeg	2009-09-03 21:25

        User since 2006-07-10 1298 articles	@sid burn Kannte ich noch nicht, sieht interessant aus. Edit: verrutscht Last edited: 2009-09-03 21:29:11 +02:00

      • 	topeg	2009-09-03 21:27

        User since 2006-07-10 1298 articles	Als ich ihn vor ein paar Jahren mal getestet habe, machte er mir ein Paar Probleme. Ich glaube ich sollte ihn nochmal ausprobieren. Edit: Satz richtig gestellt. Last edited: 2009-09-03 21:40:46 +02:00

  • +3 replies

  • 	bloonix	2009-09-04 09:24

    User since 2005-12-17 1545 articles

    Hallo Taulmarill, das Einzige, was ich von CGI verwende ist param(). Ich muss aber dazu schreiben, dass ich noch nie etwas anderes benutzt habe von CGI. Als ich mit Webprogrammierung anfing, da war es schon modern, Code und Content voneinander zu trennen und das war vor 6-7 Jahren. Seit dem war ich immer ein Freund von Template-Modulen wie zum Beispiel HTML-Template oder Template-Toolkit. Trotzallem fand CGI immer wieder Verwendung, gerade wegen param() und es wird auch in der Zukunft immer wieder bei mir Verwendung finden. VG Last edited: 2009-09-04 09:25:59 +02:00 What is a good module? That's hard to say. What is good code? That's also hard to say. One man's Thing of Beauty is another's man's Evil Hack.

    • +2 replies

    • 	renee	2009-09-04 09:39

      User since 2003-08-04 13309 articles	Hallo bloonix, in der Abstimmung geht es *nicht* um das Modul, sondern um die Schnittstelle. Und die ist ja davon unabhängig, wie Du die Applikation dahinter umsetzt. Renée $foo - Perl-Magazin (http://foo-magazin.de/) Perl-Nachrichten (http://perl-nachrichten.de/) -- http://renee-baecker.de/

      • 	bloonix	2009-09-04 09:50

        User since 2005-12-17 1545 articles	2009-09-04T07:39:52 renee Hallo bloonix, in der Abstimmung geht es *nicht* um das Modul, sondern um die Schnittstelle. Und die ist ja davon unabhängig, wie Du die Applikation dahinter umsetzt. Renée Oops, danke für den Hinweis, das hab ich überlesen :-) What is a good module? That's hard to say. What is good code? That's also hard to say. One man's Thing of Beauty is another's man's Evil Hack.