nicht angemeldet
[Plack] Ist jedoch keine Lösung für die beschrieben Mängel an CGI.pm.
Begründung fehlt.
Außerdem ergeben sich keine Vorteile gegenüber Legacy, wenn die Serverumgebung %ENV, die ein Webserver lt. CGI/1.1 Standard ohnehin anlegen muss, innerhalb von Perl gekapselt wird. Denn CGI/1.1 umfasst nämlich […] auch STDIN/STDOUT und das lässt sich gar nicht kapseln -- auch mit PSGI nicht.
Du hast den Beweggrund und die Funktionsweise von Plack überhaupt nicht verstanden. Es gibt mehr als ein Gateway-Interface. Eine Plackanwendung braucht in seinem Serverprozess nicht zwingend Umgebungsvariablen setzen, ebensowenig werden die Standardstreams gekapselt. Plack bietet eine Abstraktion über Gateway-Interfaces. Sofern der Entwickler Deployment auf CGI wünscht, werden erst dann besagte Erfordernisse reifiziert. Aber wer will/braucht schon Deployment auf CGI? Alle anderen Interfaces sind besser.
PSGI ist ein typisches Beispiel für alten Wein in neuen Schläuchen
Begründung fehlt.
Die seit 20 Jahren fällige Weiterentwicklung von CGI.pm könnte so aussehen:
Ich lachte herzlich. Früher Aprilscherz, nehme ich an‽ Willst du wirklich, dass jedes Mal, wenn du dir einen neuen Mediatype aus dem Allerwertesten popelst (netter Verstoß gegen RFC 6838 §3.1. übrigens, du Internetverderber), der Maintainer für dich persönlich Code an den Switch anfügt?
Würdest du OOP einsetzen, könntest du das mittels Polymorphismus statt Switch (http://wiki.c2.com/?ReplaceConditionalWithPolymorphism, https://sourcemaking.com/refactoring/replace-conditional-with-polymorphism) in deiner eigens abgeleiteten Klasse regeln, ohne anderen Leuten auf die Nüsse zu gehen. Und das muss auch nicht im der HTTP-Lib oder im Framework sein, es ist vollkommen kromulent, das im Clientcode zu regeln, siehe wirkliches Beispiel in http://p3rl.org/Catalyst#DATA-HANDLERS.
Und wofür gibt's eigentlich Middlewares? Öh, öhm ach ja…
Matthias Apsel
JürgenB
Camping_RIDER