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.

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.

Aber PHP läuft meines Wissens nach dort auch "nur" als cgi.

Passt finde ich auch zu diesem Thread Perl Marketing

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 +0200 (CEST)