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.
On Tue, Dec 21, 2010 at 2:22 AM, Mark Stosberg <m...@summersault.com> wrote: > Comments are currently open for the proposal for native PSGI support > in CGI::Application and CGI::Application::Dispatch. Details are here:
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.
> 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 :)
On Tue, Dec 21, 2010 at 9:21 AM, Tatsuhiko Miyagawa <miyag...@gmail.com> wrote: > On Tue, Dec 21, 2010 at 12:10 AM, Zbigniew Lukasiak <zzb...@gmail.com> wrote:
>> 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 :)
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.
On Tue, Dec 21, 2010 at 3:59 AM, Zbigniew Lukasiak <zzb...@gmail.com> wrote: >> 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 :)
> 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.
On Tue, Dec 21, 2010 at 5:47 PM, Tatsuhiko Miyagawa <miyag...@gmail.com> wrote: > On Tue, Dec 21, 2010 at 3:59 AM, Zbigniew Lukasiak <zzb...@gmail.com> wrote:
>>> 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 :)
>> 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.
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.
> On Tue, Dec 21, 2010 at 2:22 AM, Mark Stosberg <m...@summersault.com> wrote: >> Comments are currently open for the proposal for native PSGI support >> in CGI::Application and CGI::Application::Dispatch. Details are here:
> 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:
On Tue, Dec 21, 2010 at 3:39 PM, Mark Stosberg <m...@summersault.com> wrote: > On 12/21/2010 03:10 AM, Zbigniew Lukasiak wrote: >> On Tue, Dec 21, 2010 at 2:22 AM, Mark Stosberg <m...@summersault.com> wrote: >>> Comments are currently open for the proposal for native PSGI support >>> in CGI::Application and CGI::Application::Dispatch. Details are here:
>> 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.
On Fri, Dec 24, 2010 at 10:21 AM, Zbigniew Lukasiak <zzb...@gmail.com> wrote: > On Tue, Dec 21, 2010 at 3:39 PM, Mark Stosberg <m...@summersault.com> wrote: >> On 12/21/2010 03:10 AM, Zbigniew Lukasiak wrote: >>> On Tue, Dec 21, 2010 at 2:22 AM, Mark Stosberg <m...@summersault.com> wrote: >>>> Comments are currently open for the proposal for native PSGI support >>>> in CGI::Application and CGI::Application::Dispatch. Details are here:
>>> 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.
