Proposed native PSGI support for CGI::Application and CGI::Appliication::Dispatch
Mark Stosberg
in CGI::Application and CGI::Application::Dispatch. Details are here:
http://permalink.gmane.org/gmane.comp.lang.perl.modules.cgi-appplication/8268
I'm currently waiting to hear back from Alex Kapranoff about
permission to upload the proposed update in the namespace of
CGI::Application::Dispatch::PSGI.
I hope to upload final designs to CPAN in the next few days.
Mark
Zbigniew Lukasiak
> Comments are currently open for the proposal for native PSGI support
> in CGI::Application and CGI::Application::Dispatch. Details are here:
>
> http://permalink.gmane.org/gmane.comp.lang.perl.modules.cgi-appplication/8268
Ad. psgi_app - I wish there was a standard among the object oriented
web frameworks here. Then all the startup scripts would be the same,
or maybe we could even have a plackup extension that would call this
static method when passed just the class name and no .psgi file.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
Tatsuhiko Miyagawa
>>
>> http://permalink.gmane.org/gmane.comp.lang.perl.modules.cgi-appplication/8268
>
> Ad. psgi_app - I wish there was a standard among the object oriented
> web frameworks here. Then all the startup scripts would be the same,
> or maybe we could even have a plackup extension that would call this
> static method when passed just the class name and no .psgi file.
To me that sounds like an unnecessary abstraction.
Some frameworks require setting up engines, allow configuration
options to ->new() etc. You'll lose them by sticking the universal
interface i.e. MyApp->psgi_app.
PSGI embraces diversity, and to me, inconsistency is a good thing.
Note that we used to have Plack::Adapter::(YourFrameworkNameHere) when
Plack was 3-4 days old, which was soon killed since it was not a good
idea :)
https://github.com/miyagawa/Plack/commit/02f2bff02ca2a3a1353c3b89e2ab4e60df911c7f
--
Tatsuhiko Miyagawa
Zbigniew Lukasiak
OK - I understand, diversity is important, I completely agree. I not
yet worked with frameworks that require setting up an engine and I do
configuration in the application not in the .psgi file - so I don't
know. But just to explain myself: for me (as a framework author) the
name of the ->psgi_app method is a free variable and it can be
anything, so why not something standard? That does not mean I would
go as far as using the mentioned Adapter - that adds new code and
there is always some cost to that - but changing the name of the
'->psgi_app' method does not cost me anything.
Tatsuhiko Miyagawa
>> Some frameworks require setting up engines, allow configuration
>> options to ->new() etc. You'll lose them by sticking the universal
>> interface i.e. MyApp->psgi_app.
>>
>> PSGI embraces diversity, and to me, inconsistency is a good thing.
>>
>> Note that we used to have Plack::Adapter::(YourFrameworkNameHere) when
>> Plack was 3-4 days old, which was soon killed since it was not a good
>> idea :)
>>
>> https://github.com/miyagawa/Plack/commit/02f2bff02ca2a3a1353c3b89e2ab4e60df911c7f
>>
>
> OK - I understand, diversity is important, I completely agree. I not
> yet worked with frameworks that require setting up an engine and I do
> configuration in the application not in the .psgi file - so I don't
> know.
Also note that some frameworks allows applications be classless i.e.
Mojolicious::Lite and Dancer.
> But just to explain myself: for me (as a framework author) the
> name of the ->psgi_app method is a free variable and it can be
> anything, so why not something standard?
Sure, if you write a new framework and some guidance for a naming
that's fine. But that "standard" doesn't work as a standard unless we
change all the existing frameworks to adapt to the proposal. Otherwise
it's just a "convention that some frameworks follow but not all, hence
not that useful".
> That does not mean I would
> go as far as using the mentioned Adapter - that adds new code and
> there is always some cost to that - but changing the name of the
> '->psgi_app' method does not cost me anything.
Right, it doesn't cost *you* anything to pick that name, but it will
cost others once you propose it as a standard and force other authors
to update the names and syntax.
Speaking of calling plackup with the class names, plackup already has
a secret (as in, barely used i think) feature to take a class name as
its app argument. The logic is in Plack::Util::load_psgi - if the
given app name doesn't contain ".", treat it as a class name, require
it, and take the return value of the .pm (usually 1 but could be
anything in perl, you know) as a PSGI code ref.
It was added a few months ago as a result of IRC discussion, but i'm
yet neutral on this i.e. i'm happy to kill this feature.
--
Tatsuhiko Miyagawa
Zbigniew Lukasiak
Thanks for the explanations. I like that undocumented option - I have
some plans to make it possible to run WebNano apps directly from the
command line without creating a special directory for them and any
additional files beside what is in the CPAN distribution. Perhaps
this would not make much sense for an application in production - but
it would eliminate one more step when checking CPAN distributed apps.
Mark Stosberg
> On Tue, Dec 21, 2010 at 2:22 AM, Mark Stosberg <ma...@summersault.com> wrote:
>> Comments are currently open for the proposal for native PSGI support
>> in CGI::Application and CGI::Application::Dispatch. Details are here:
>>
>> http://permalink.gmane.org/gmane.comp.lang.perl.modules.cgi-appplication/8268
>
> Ad. psgi_app - I wish there was a standard among the object oriented
> web frameworks here. Then all the startup scripts would be the same,
> or maybe we could even have a plackup extension that would call this
> static method when passed just the class name and no .psgi file.
I am open to changing this name is there are a few other frameworks that
have the same API, but different names. But, I think Miyagawa may be
right that there are too many other different details for there to be
really be a standard.
We this with Emplacken, it has different code for calling Catalyst,
Dancer, Mason and Mojo:
http://search.cpan.org/dist/Emplacken/
Mark
Zbigniew Lukasiak
> On 12/21/2010 03:10 AM, Zbigniew Lukasiak wrote:
>> On Tue, Dec 21, 2010 at 2:22 AM, Mark Stosberg <ma...@summersault.com> wrote:
>>> Comments are currently open for the proposal for native PSGI support
>>> in CGI::Application and CGI::Application::Dispatch. Details are here:
>>>
>>> http://permalink.gmane.org/gmane.comp.lang.perl.modules.cgi-appplication/8268
>>
>> Ad. psgi_app - I wish there was a standard among the object oriented
>> web frameworks here. Then all the startup scripts would be the same,
>> or maybe we could even have a plackup extension that would call this
>> static method when passed just the class name and no .psgi file.
>
> I am open to changing this name is there are a few other frameworks that
> have the same API, but different names. But, I think Miyagawa may be
> right that there are too many other different details for there to be
> really be a standard.
OK - I'll change mine to yours :) Just to open the possibilities.
Z.
Zbigniew Lukasiak
Done in https://github.com/zby/WebNano/commit/b4b804a19187b5194557cf2e6247f14212813fea
I also checked Dancer - it uses psgi_app as well - so it seems like a
good choice.
Cheers,
Z.