Announce: CGI::Snapp::Dispatch V 1.00 etc, with PSGI support
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Announce: CGI::Snapp::Dispatch V 1.00 etc, with PSGI support
by Ron Savage
::
Rate this Message:
Hi Folks
I've uploaded to CPAN: o CGI::Snapp::Dispatch V 1.00. This distro includes CGI::Snapp::Dispatch::Regexp. Both modules support usage in a PSGI environment. This module is a partner for CGI::Snapp, and together they are almost drop-in replacements for CGI::Application, CGI::Application::Dispatch, CGI::Application::Dispatch::Regexp and CGI::Application::Dispatch::PSGI. The default for logging is to not create a logger, as per CGI::Snapp V 1.01 below. There are 63 tests. PSGI is supported without needing a module called CGI::Snapp::Dispatch::PSGI. o CGI::Snapp V 1.01. This has a new mutator _psgi() for use by CGI::Snapp::Dispatch. Also, the default for logging is now to not create a logger. PSGI is supported without needing a module called CGI::Snapp::PSGI. o CGI::Snapp::Plugin::Forward V 1.01. The tests explicitly create a logger since CGI::Snapp V 1.01 now does not. o CGI::Snapp::Plugin::Redirect V 1.01. The tests explicitly create a logger since CGI::Snapp V 1.01 now does not. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: Announce: CGI::Snapp::Dispatch V 1.00 etc, with PSGI support
by estravd
::
Rate this Message:
On Thu, Apr 12, 2012 at 01:29:37PM +1000, Ron Savage wrote:
> Hi Folks > > I've uploaded to CPAN: > > o CGI::Snapp::Dispatch V 1.00. > > This distro includes CGI::Snapp::Dispatch::Regexp. > > Both modules support usage in a PSGI environment. > > This module is a partner for CGI::Snapp, and together they are almost > drop-in replacements for CGI::Application, CGI::Application::Dispatch, > CGI::Application::Dispatch::Regexp and CGI::Application::Dispatch::PSGI. > > The default for logging is to not create a logger, as per CGI::Snapp V > 1.01 below. > > There are 63 tests. > > PSGI is supported without needing a module called > CGI::Snapp::Dispatch::PSGI. > > o CGI::Snapp V 1.01. > > This has a new mutator _psgi() for use by CGI::Snapp::Dispatch. > > Also, the default for logging is now to not create a logger. > > PSGI is supported without needing a module called CGI::Snapp::PSGI. > > o CGI::Snapp::Plugin::Forward V 1.01. > > The tests explicitly create a logger since CGI::Snapp V 1.01 now does not. > > o CGI::Snapp::Plugin::Redirect V 1.01. > > The tests explicitly create a logger since CGI::Snapp V 1.01 now does not. Ron, Congratulations and nice work. I am sorry to be dense, but as long as I've been following Snapp and as many of the docs that I seem to have read, I am still trying to figure out exactly what Snapp gives us over CAP. I ask because I am at the start of a major project that is making critical use of CAP and CAP::Dispatch. If I am going to switch, now's the time, but I need to justify it to myself. Thank you, Brett > > > -- > Ron Savage > http://savage.net.au/ > Ph: 0421 920 622 > > ##### CGI::Application community mailing list ################ > ## ## > ## To unsubscribe, or change your message delivery options, ## > ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: Announce: CGI::Snapp::Dispatch V 1.00 etc, with PSGI support
by Ron Savage
::
Rate this Message:
Hi Brett
On 13/04/12 01:34, B. Estrade wrote: > On Thu, Apr 12, 2012 at 01:29:37PM +1000, Ron Savage wrote: > > Congratulations and nice work. I am sorry to be dense, but as long as > I've been following Snapp and as many of the docs that I seem to have > read, I am still trying to figure out exactly what Snapp gives us over > CAP. > > I ask because I am at the start of a major project that is making > critical use of CAP and CAP::Dispatch. If I am going to switch, now's > the time, but I need to justify it to myself. A perfectly reasonable request. As I've hinted, with great restraint, in: https://metacpan.org/module/CGI::Snapp#Why-did-you-fork-CGI::Application- I been struggling with Mark Stosberg for years about timely releases of patches (mostly to CGI::Session). I have written a great deal of code and docs, some of which he withheld from release for more than a year. I eventually decided for re-write this code so as to free myself from that constraint. In other words, I wished to guarantee current and future support - by doing it myself - for my current and future projects. That does not mean I have to use CGI::Snapp for everything. In fact, I'm very tempted to start learning Mojo, but I wanted a safe and reliable alternative to be in place before I adopted something new, since the latter course would necessarily involve a learning curve. The other factor you - and everyone - should take into account is that CGI::App etc appear to be longer supported, in that bug fixing has stopped. CGI::Snapp etc bugs (if any!) will be of great concern to me and will be fixed ASAP. For such software technology, it's actually nice to have a choice. Choose wisely! -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: Announce: CGI::Snapp::Dispatch V 1.00 etc, with PSGI support
by David Groskind
::
Rate this Message:
Reading the email exchange below, it looks like CGI::Application has
stalled and one of the developers has forked the code. There are enough differences with the forked version that I would stick with CGI::App. On Thu, Apr 12, 2012 at 7:30 PM, Ron Savage <ron@...> wrote: > Hi Brett > > On 13/04/12 01:34, B. Estrade wrote: > > On Thu, Apr 12, 2012 at 01:29:37PM +1000, Ron Savage wrote: > > > > Congratulations and nice work. I am sorry to be dense, but as long as > > I've been following Snapp and as many of the docs that I seem to have > > read, I am still trying to figure out exactly what Snapp gives us over > > CAP. > > > > I ask because I am at the start of a major project that is making > > critical use of CAP and CAP::Dispatch. If I am going to switch, now's > > the time, but I need to justify it to myself. > > A perfectly reasonable request. > > As I've hinted, with great restraint, in: > > https://metacpan.org/module/CGI::Snapp#Why-did-you-fork-CGI::Application- > > I been struggling with Mark Stosberg for years about timely releases of > patches (mostly to CGI::Session). I have written a great deal of code > and docs, some of which he withheld from release for more than a year. > > I eventually decided for re-write this code so as to free myself from > that constraint. In other words, I wished to guarantee current and > future support - by doing it myself - for my current and future projects. > > That does not mean I have to use CGI::Snapp for everything. In fact, I'm > very tempted to start learning Mojo, but I wanted a safe and reliable > alternative to be in place before I adopted something new, since the > latter course would necessarily involve a learning curve. > > The other factor you - and everyone - should take into account is that > CGI::App etc appear to be longer supported, in that bug fixing has stopped. > > CGI::Snapp etc bugs (if any!) will be of great concern to me and will be > fixed ASAP. > > For such software technology, it's actually nice to have a choice. > > Choose wisely! > > > -- > Ron Savage > http://savage.net.au/ > Ph: 0421 920 622 > > ##### CGI::Application community mailing list ################ > ## ## > ## To unsubscribe, or change your message delivery options, ## > ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > > ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: Announce: CGI::Snapp::Dispatch V 1.00 etc, with PSGI support
by Ron Savage
::
Rate this Message:
Hi David
On 13/04/12 12:39, David Groskind wrote: > Reading the email exchange below, it looks like CGI::Application has > stalled and one of the developers has forked the code. > > There are enough differences with the forked version that I would stick > with CGI::App. There have to be some differences, otherwise there's not much point in a fork... Also, I've written or re-written all the documentation for my modules, and hopefully made them vastly easier to read. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: Announce: CGI::Snapp::Dispatch V 1.00 etc, with PSGI support
by Nic Zero
::
Rate this Message:
I too have recently rewritten CGI::App and most of its core plugins.
That was not my original plan. You may remember recently I was recommending people make use of class-level initialisation and only do object-level initialisation (ie per cgiapp instance) for those things that can't be shared. However, when I looked into it more deeply (as part of a separate task) I found that support for this within plugins is quite sketchy and unreliable. CGI::App itself doesn't really support the idea in any clear way. I also thought that rearranging the code inside CGI::App would help me and others understand the flow better. So I started to refactor. But then I encountered code that is convoluted, for example a six- line subroutine that was much clearer in one line. So I started to rewrite. And then I decided the whole thing would be easier to code against as well as easier to read if I made my Stash plugin be used within CGI::App itself (much like Catalyst & Mojolicious). So then I realised I was departing from being CGI::App compatible. That's where that story ends. As soon as you've broken compatibility you've distanced yourself from the CGI::App community and your one-man project is dead. My time wasn't wasted cos I then refactored again so that the good bits are separate extensions that can be used with CGI::App or Mojolicious. [They're close to being published; tests need to be improved and documentation needs to catch up.] I thought that my micro-framework would still fill a niche: those cases where you want the functionality of Catalyst but with a 1 MB du footprint. Unfortunately those smart people over at Mojolicious had a fabulous 2011 and can do much more than my framework and still sit inside 1 MB. So if you're still reading, my strong recommendations are: * Respect CGI::App for what it is. If you need more, go see Mojolicious::Lite and Mojolicious itself. * Ignore people like Ron & me who are tempted to do rewrites that will never have the community that CGI::App grew. Two years from now both of our frameworks will still contain more bugs and fewer working examples than CGI::App. * Ron, if you do continue with Snapp, try borrowing some of the smart ideas from Mojolicious::Lite, but * like me, I suspect you'll fall in love with Mojolicious and Snapp will just be an amusing memory. Happy coding, Nic ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: Announce: CGI::Snapp::Dispatch V 1.00 etc, with PSGI support
by estravd
::
Rate this Message:
On Fri, Apr 13, 2012 at 06:48:34AM -0400, Nic Zero wrote:
> I too have recently rewritten CGI::App and most of its core plugins. > That was not my original plan.?? You may remember recently I was > recommending people make use of class-level initialisation and > only do object-level initialisation (ie per cgiapp instance) for those > things that can't be shared.?? However, when I looked into it more > deeply (as part of a separate task) I found that support for this > within plugins is quite sketchy and unreliable.?? CGI::App itself > doesn't really support the idea in any clear way.?? I also thought > that rearranging the code inside CGI::App would help me and > others understand the flow better.?? So I started to refactor.?? But > then I encountered code that is convoluted, for example a six- > line subroutine that was much clearer in one line.?? So I started > to rewrite.?? And then I decided the whole thing would be easier to > code against as well as easier to read if I made my Stash plugin > be used within CGI::App itself (much like Catalyst & Mojolicious). > So then I realised I was departing from being CGI::App > compatible. > > That's where that story ends.?? As soon as you've broken > compatibility you've distanced yourself from the CGI::App > community and your one-man project is dead.?? My time wasn't > wasted cos I then refactored again so that the good bits are > separate extensions that can be used with CGI::App or > Mojolicious.?? [They're close to being published; tests need to > be improved and documentation needs to catch up.] ..ah, yes..the community - that's the compelling part about CAP for me. I like this list a lot, for example. > > I thought that my micro-framework would still fill a niche: those > cases where you want the functionality of Catalyst but with a > 1 MB du footprint.?? Unfortunately those smart people over at > Mojolicious had a fabulous 2011 and can do much more than > my framework and still sit inside 1 MB. > > So if you're still reading, my strong recommendations are: > * Respect CGI::App for what it is.?? If you need more, go see > Mojolicious::Lite and Mojolicious itself. > * Ignore people like Ron & me who are tempted to do rewrites > that will never have the community that CGI::App grew.?? Two > years from now both of our frameworks will still contain more > bugs and fewer working examples than CGI::App. I am less inclined to use something other than CAP proper, but Mojolicious looks interesting. Something about how much it hides is a little unerving to me, though. I have routes set up fine using CAP::Dispatch (which also supports the HTTP methods for the clean URIs. Beyond setting up the routes, I am not sure what Mojo gives me since I still have to implement my backend to push and pull data. It is a lot cleaner looking, but one thing that stands out to me are those templates in Mojo - out of the box, they seem way to powerful (I am a fan of super dumb templates). > * Ron, if you do continue with Snapp, try borrowing some of > the smart ideas from Mojolicious::Lite, but > * like me, I suspect you'll fall in love with Mojolicious and > Snapp will just be an amusing memory. Thanks, everyone. And thanks, Ron, for your efforts - I don't think any effort to improve things or to learn is time wasted. Most OSS projects out there are "one man" or "one off". I have a few myself =). Brett > > Happy coding, > Nic > > ##### CGI::Application community mailing list ################ > ## ## > ## To unsubscribe, or change your message delivery options, ## > ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > > ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: Announce: CGI::Snapp::Dispatch V 1.00 etc, with PSGI support
by Ron Savage
::
Rate this Message:
Hi Nic
On 13/04/12 20:48, Nic Zero wrote: > * Ignore people like Ron& me who are tempted to do rewrites > that will never have the community that CGI::App grew. Two > years from now both of our frameworks will still contain more > bugs and fewer working examples than CGI::App. My plan is that Snapp will always contain less bugs :-). > * Ron, if you do continue with Snapp, try borrowing some of > the smart ideas from Mojolicious::Lite, but > * like me, I suspect you'll fall in love with Mojolicious and > Snapp will just be an amusing memory. Quite possibly, but the code will not suffer bit rot. It definitely will be maintained. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: Announce: CGI::Snapp::Dispatch V 1.00 etc, with PSGI support
by Ron Savage
::
Rate this Message:
Hi Brett
On 14/04/12 00:59, B. Estrade wrote: > On Fri, Apr 13, 2012 at 06:48:34AM -0400, Nic Zero wrote: > ..ah, yes..the community - that's the compelling part about CAP for > me. I like this list a lot, for example. Agreed. I released Snapp publicly just so the community can use it. > I am less inclined to use something other than CAP proper, but > Mojolicious looks interesting. Something about how much it hides is a > little unerving to me, though. It's always a bit of a risk to change direction away from a well-recognized module to an alternative, since you are - at first - entering the unknown. But you did that by adopting CAP originally. I have precisely the same reaction as you to Mojolicious' automated-hamburger-with-the-lot approach. > I have routes set up fine using CAP::Dispatch (which also supports the > HTTP methods for the clean URIs. Beyond setting up the routes, I am > not sure what Mojo gives me since I still have to implement my backend > to push and pull data. It is a lot cleaner looking, but one thing that > stands out to me are those templates in Mojo - out of the box, they > seem way to powerful (I am a fan of super dumb templates). Yes - it's writing the real guts of the app which is always the challenge, and I do love to see how others have done it, since I'm very visual like that. If too much is automated, what's to see? My choice of templater is Text::Xslate. >> * Ron, if you do continue with Snapp, try borrowing some of >> the smart ideas from Mojolicious::Lite, but >> * like me, I suspect you'll fall in love with Mojolicious and >> Snapp will just be an amusing memory. > > Thanks, everyone. And thanks, Ron, for your efforts - I don't think > any effort to improve things or to learn is time wasted. Most OSS > projects out there are "one man" or "one off". I have a few myself =). Thanx for the positive feedback. I'm delighted to say I don't think any of my time was wasted. As some of you might know, I take care of my mother who has Alzheimer's, so I'm at home all day with plenty of time available. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
CGI::Application status update from the maintainer
by Mark Stosberg
::
Rate this Message:
Hello Everyone. I'll start with a apology about not being as present as I intended. Messages from this list were not coming directly to my Inbox for some time, and it took me longer than I wanted to get that addressed. Starting today, messages should be going back in my Inbox again, and I will attempt be more responsive here. I'm still alive and well, and use and support CGI::Application every day at work. I'm also now the primary maintainer of CGI.pm. While it's only a part of the CGI::Application framework, it has substantially more lines of code, as well as more bugs and bug traffic. More of my maintenance time has been spent maintaining that lately. I appreciate the fork that Ron Savage recently published, because it's good to explore options, and it's easiest to evaluate options if they are complete. I also agree with the spirit of it. It's time for the next generation of the framework, one that breaks compatibility in some places to move the whole forward. I started writing my own fork over a year ago in hopes of having something to share around the time for YAPC 2011. While I needed to put that on hold for a while, It's now on the verge of the initial release. It was interesting to find Ron's fork which had been developed independently and in parallel, to see where we agreed and where we differed. Here are the key points I have mind for the update I'll be publishing soon: - A new name space, to avoid confusion and problems with API changes. - A "::Compat" addition that allows people to keep using a maximal amount of the old API if they need to. (Including a certain amount of plugins) - PSGI-native. I'm excited that Perl web frameworks are converging here. We'll be able to take advantage of PSGI "Middleware" that was designed with other frameworks in mind. Many things that were CGI::App plugins before are now better done done as PSGI "Middleware". As a plugin author, you get the benefit of having more users who may be using other frameworks. The difference with CGI::App will be that PSGI will the *only* code path supported. - Uses Any::Moose / Mouse. I endorse the Moose API and Mouse brings much of that API to lower resource environments, like the CGI environment where CGI::Application has always performed well. It's already possible to write a CGI::App subclass based on Moose or Mouse, but like with PSGI, I think it's in our best interest to upgrade to first class support. Just as "PSGI Middleware" presents a new opportunity for code re-use, Moose/Mouse "roles" present another alternative to "plugins" that can be shared between frameworks. For example, methods for logging, database access and "config" data are all good candidates to be implemented as roles. - Templating APIs removed from core, for now. We'll get a new templating API, although the details are still TBD. - Plans to replace CGI.pm with request and response objects. As the CGI.pm maintainer, I could devote another full post to reasons why I don't to be using it in another 5 or 10 years. Details here are still to be determined as well. Immediately we would see the "query()" method replaced with a "req" method to represent a "request" object. HTTP has "requests" and "responses". The idea of a "query object" is a CGI.pm'ism to leave behind. About every other Perl framework I've looked at models the response and request this way, and it's time we implemented this sensible design as well. - The popular and small "::Forward()" and "::Redirect()" plugins will be merged into the core. As part of considering the future of CGI::Application, I did consider just dropping it. I maintain it, but lack the emotional attachment of being the original author. I stepped back and took a look at it from the distance and compared it to alternatives. Outside of the few "details" I'd like to change, I find the core of it still offers a unique combination of design properties that I think are worth taking forward: - I think the flow of the execution stages works very well. I'm talking about "init", "setup", "prerun", "run", "postrun", "teardown", as they are implemented in "new()" and "run()". - Lightweight / fast start up time. - Simple. Less code to learn, less chance for bugs. - Global dispatching. That is, a single central table, rather than storing dispatch details "locally", with each run mode. - Ability to scale up. I find CGI::App suitable for large projects as well as small. There's also a great community of people and plugins around CGI::App as well. I look forward to being conversation with you all more about this. I'll set a goal to release the first code-as-draft for my proposal within a week, and look forward to your feedback to sculpt it into a releasable form. Thanks, Mark ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: CGI::Application status update from the maintainer
by Gabor Szabo-4
::
Rate this Message:
On Wed, Aug 29, 2012 at 6:27 AM, Mark Stosberg <mark@...> wrote:
> I'll start with a apology about not being as present as I intended. No need for that. > I started writing my own fork over a year ago in hopes of having > something to share around the time for YAPC 2011. While I needed to put > that on hold for a while, It's now on the verge of the initial release. > Here are the key points I have mind for the update I'll be publishing > soon: > > - A new name space, to avoid confusion and problems with API changes. My bike-shed request is to avoid the word CGI :) Otherwise I applaud your work and plans! Thank you! regards Gabor ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: CGI::Application status update from the maintainer
by Jiří Pavlovský
::
Rate this Message:
On 29.8.2012 8:26, Gabor Szabo wrote:
> I started writing my own fork over a year ago in hopes of having > something to share around the time for YAPC 2011. While I needed to put > that on hold for a while, It's now on the verge of the initial release. >> Here are the key points I have mind for the update I'll be publishing >> soon: >> >> - A new name space, to avoid confusion and problems with API changes. > My bike-shed request is to avoid the word CGI :) > > I agree that well chosen name is crucial for taking over the world ;) -- Jiří Pavlovský ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: CGI::Application status update from the maintainer
by Mark Stosberg
::
Rate this Message:
>> I started writing my own fork over a year ago in hopes of having >> something to share around the time for YAPC 2011. While I needed to put >> that on hold for a while, It's now on the verge of the initial release. > >> Here are the key points I have mind for the update I'll be publishing >> soon: >> >> - A new name space, to avoid confusion and problems with API changes. > > My bike-shed request is to avoid the word CGI :) Gabor, Thanks for the feedback. Your request will be granted. Mark ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: CGI::Application status update from the maintainer
by Michael Peters
::
Rate this Message:
On 08/28/2012 11:27 PM, Mark Stosberg wrote:
> I look forward to being conversation with you all more about this. I'll > set a goal to release the first code-as-draft for my proposal within a > week, and look forward to your feedback to sculpt it into a releasable > form. I agree with just about everything you've mentioned here Mark. I've been thinking myself that C::A needed to be "reinvented" as something more modern but that still had the same flavor. My only advice is that since you'll really only have this one time to make a break like this from the past, don't feel bad about breaking backward compatibility. From your email it doesn't seem like you do, just wanted to make sure that you knew we'd support something like that. And like Gabor said, avoid the word "CGI" :) I know we've been down the naming rabbit hole before and it makes all the bikeshedders come out, a good unique, google-able name would be nice. And naming writes go to the man who does the work, so enjoy :) -- Michael Peters Plus Three, LP ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: CGI::Application status update from the maintainer
by Jolly.Tall
::
Rate this Message:
Hi Mark,
I also use C::A everyday - my main application that I wrote and maintain is a C::A. You are of course right that C::A uses some out-of-date procedures like the query method. But since C::A first appeared we now have newer frameworks like Catalyst, Mojo, and the more recent Dancer (also in the process of being rewritten to embrace the Moose API). Given that Ron has already forked C::A I wonder if there is any point embarking on another? Accepting that Catalyst is not to everyones taste, and Dancer may not yet have the recognition and presence that Catalyst and Mojo/Mojolicious have as web frameworks, I'm wondering what advantage a revamped C::A under a new name will provide. One essential item for any web framework is a competent dispatcher, something I think compromises Dancer v1 (hopefully addressed in v2), essential for an application with a large number of run-modes (or equivalents). C::A::Dispatch or a core equivalent is a must IMO. I'm not sure if that is what you had in mind with "global dispatching". Still, best wishes for C::A mark II if you decide to go through with it, and looking forward to seeing the draft code later this week :) On 29/08/2012 04:27, Mark Stosberg wrote: > > Hello Everyone. > > I'll start with a apology about not being as present as I intended. > Messages from this list were not coming directly to my Inbox for some > time, and it took me longer than I wanted to get that addressed. > Starting today, messages should be going back in my Inbox again, and I > will attempt be more responsive here. > > I'm still alive and well, and use and support CGI::Application every day > at work. I'm also now the primary maintainer of CGI.pm. While it's only > a part of the CGI::Application framework, it has substantially more > lines of code, as well as more bugs and bug traffic. More of my > maintenance time has been spent maintaining that lately. > > I appreciate the fork that Ron Savage recently published, because it's > good to explore options, and it's easiest to evaluate options if they > are complete. I also agree with the spirit of it. It's time for the next > generation of the framework, one that breaks compatibility in some > places to move the whole forward. > > I started writing my own fork over a year ago in hopes of having > something to share around the time for YAPC 2011. While I needed to put > that on hold for a while, It's now on the verge of the initial release. > It was interesting to find Ron's fork which had been developed > independently and in parallel, to see where we agreed and where we > differed. > > Here are the key points I have mind for the update I'll be publishing > soon: > > - A new name space, to avoid confusion and problems with API changes. > > - A "::Compat" addition that allows people to keep using a maximal > amount of the old API if they need to. (Including a certain amount of > plugins) > > - PSGI-native. I'm excited that Perl web frameworks are converging here. > We'll be able to take advantage of PSGI "Middleware" that was designed > with other frameworks in mind. Many things that were CGI::App plugins > before are now better done done as PSGI "Middleware". As a plugin > author, you get the benefit of having more users who may be using > other frameworks. The difference with CGI::App will be that PSGI will > the *only* code path supported. > > - Uses Any::Moose / Mouse. I endorse the Moose API and Mouse brings > much of that API to lower resource environments, like the CGI > environment where CGI::Application has always performed well. > > It's already possible to write a CGI::App subclass based on Moose or > Mouse, but like with PSGI, I think it's in our best interest to > upgrade to first class support. > > Just as "PSGI Middleware" presents a new opportunity for code re-use, > Moose/Mouse "roles" present another alternative to "plugins" that can > be shared between frameworks. For example, methods for logging, > database access and "config" data are all good candidates to be > implemented as roles. > > - Templating APIs removed from core, for now. We'll get a new templating > API, although the details are still TBD. > > - Plans to replace CGI.pm with request and response objects. As the > CGI.pm maintainer, I could devote another full post to reasons why I > don't to be using it in another 5 or 10 years. Details here are still > to be determined as well. > > Immediately we would see the "query()" method replaced with a "req" > method to represent a "request" object. HTTP has "requests" and > "responses". The idea of a "query object" is a CGI.pm'ism to leave > behind. > > About every other Perl framework I've looked at models the response > and request this way, and it's time we implemented this sensible > design as well. > > > - The popular and small "::Forward()" and "::Redirect()" plugins will > be merged into the core. > > As part of considering the future of CGI::Application, I did consider > just dropping it. I maintain it, but lack the emotional attachment of > being the original author. I stepped back and took a look at it from the > distance and compared it to alternatives. Outside of the few "details" > I'd like to change, I find the core of it still offers a unique > combination of design properties that I think are worth taking forward: > > - I think the flow of the execution stages works very well. I'm talking > about "init", "setup", "prerun", "run", "postrun", "teardown", as > they are implemented in "new()" and "run()". > > - Lightweight / fast start up time. > > - Simple. Less code to learn, less chance for bugs. > > - Global dispatching. That is, a single central table, rather than > storing dispatch details "locally", with each run mode. > > - Ability to scale up. I find CGI::App suitable for large projects as > well as small. > > There's also a great community of people and plugins around CGI::App as > well. > > I look forward to being conversation with you all more about this. I'll > set a goal to release the first code-as-draft for my proposal within a > week, and look forward to your feedback to sculpt it into a releasable > form. > > Thanks, > > Mark > > > ##### CGI::Application community mailing list ################ > ## ## > ## To unsubscribe, or change your message delivery options, ## > ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > -- Richard Jones ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: CGI::Application status update from the maintainer
by estravd
::
Rate this Message:
Thank you, Mark. Responses are inlined.
On Tue, Aug 28, 2012 at 11:27:04PM -0400, Mark Stosberg wrote: > > Hello Everyone. > > I'll start with a apology about not being as present as I intended. > Messages from this list were not coming directly to my Inbox for some > time, and it took me longer than I wanted to get that addressed. > Starting today, messages should be going back in my Inbox again, and I > will attempt be more responsive here. > > I'm still alive and well, and use and support CGI::Application every day > at work. I'm also now the primary maintainer of CGI.pm. While it's only > a part of the CGI::Application framework, it has substantially more > lines of code, as well as more bugs and bug traffic. More of my > maintenance time has been spent maintaining that lately. > > I appreciate the fork that Ron Savage recently published, because it's > good to explore options, and it's easiest to evaluate options if they > are complete. I also agree with the spirit of it. It's time for the next > generation of the framework, one that breaks compatibility in some > places to move the whole forward. > > I started writing my own fork over a year ago in hopes of having > something to share around the time for YAPC 2011. While I needed to put > that on hold for a while, It's now on the verge of the initial release. > It was interesting to find Ron's fork which had been developed > independently and in parallel, to see where we agreed and where we > differed. It strikes me that CAP is more of a "way" or standard than any particular implementation, even though I think it could certainly be standardized or have that one true reference implementation. > > Here are the key points I have mind for the update I'll be publishing > soon: > > - A new name space, to avoid confusion and problems with API changes. > > - A "::Compat" addition that allows people to keep using a maximal > amount of the old API if they need to. (Including a certain amount of > plugins) Or maybe just do something like how perl5 turns on new version based features (e.g., use CGI::Application q/1.2.3/;). > > - PSGI-native. I'm excited that Perl web frameworks are converging here. > We'll be able to take advantage of PSGI "Middleware" that was designed > with other frameworks in mind. Many things that were CGI::App plugins > before are now better done done as PSGI "Middleware". As a plugin > author, you get the benefit of having more users who may be using > other frameworks. The difference with CGI::App will be that PSGI will > the *only* code path supported. Nice. I would like to warn that traditional persistent environments will continue to remain relevant, and I think it's a mistake to discount this. Additionally, from what I have seen from the other frameworks, nothing solves anything in principle beyond what CAP does. Some make it easier to define runmodes or to set up dispatching, but you still need to properly create a proper MVC separation and set of supporting modules. It's the same amount of work no matter what you use. > > - Uses Any::Moose / Mouse. I endorse the Moose API and Mouse brings > much of that API to lower resource environments, like the CGI > environment where CGI::Application has always performed well. > > It's already possible to write a CGI::App subclass based on Moose or > Mouse, but like with PSGI, I think it's in our best interest to > upgrade to first class support. I am not sure what this buys anyone, to be frank. I know that using these object layering might incite some sort of religious war. Ultimately, this decision is clearly in the hands of those who do the work. I have my reservations about moving away from Perlish idioms and towards the oop flavors of the week. Any core might be well served by avoiding any sort of meta object sugar over the long haul. I think my overall point is that CAP and what it provides is timeless. The pendulum swings both ways, and it would be nice to see CAP focus on improving its strengths and not trying to do what the other kids might be doing. > > Just as "PSGI Middleware" presents a new opportunity for code re-use, > Moose/Mouse "roles" present another alternative to "plugins" that can > be shared between frameworks. For example, methods for logging, > database access and "config" data are all good candidates to be > implemented as roles. > > - Templating APIs removed from core, for now. We'll get a new templating > API, although the details are still TBD. > > - Plans to replace CGI.pm with request and response objects. As the > CGI.pm maintainer, I could devote another full post to reasons why I > don't to be using it in another 5 or 10 years. Details here are still > to be determined as well. > > Immediately we would see the "query()" method replaced with a "req" > method to represent a "request" object. HTTP has "requests" and > "responses". The idea of a "query object" is a CGI.pm'ism to leave > behind. > > About every other Perl framework I've looked at models the response > and request this way, and it's time we implemented this sensible > design as well. I think I am not really clear on what change in perspective means. Is it truly a semantic change or is it just a different name? I am somewhat familiar with some of the other new fangled frameworks, but not well enough to know what the difference is between this request/response versus query objects. > > > - The popular and small "::Forward()" and "::Redirect()" plugins will > be merged into the core. It would be really nice to merge in some bare bones Authentication and Authorization support - maybe ever by more fully developing CAP's lifecycle. > > As part of considering the future of CGI::Application, I did consider > just dropping it. I maintain it, but lack the emotional attachment of > being the original author. I stepped back and took a look at it from the > distance and compared it to alternatives. Outside of the few "details" > I'd like to change, I find the core of it still offers a unique > combination of design properties that I think are worth taking forward: > > - I think the flow of the execution stages works very well. I'm talking > about "init", "setup", "prerun", "run", "postrun", "teardown", as > they are implemented in "new()" and "run()". > > - Lightweight / fast start up time. > > - Simple. Less code to learn, less chance for bugs. > > - Global dispatching. That is, a single central table, rather than > storing dispatch details "locally", with each run mode. > > - Ability to scale up. I find CGI::App suitable for large projects as > well as small. > > There's also a great community of people and plugins around CGI::App as > well. I am a recent addition to this community, and prefer CAP well over the other alternatives. > > I look forward to being conversation with you all more about this. I'll > set a goal to release the first code-as-draft for my proposal within a > week, and look forward to your feedback to sculpt it into a releasable > form. Here are some items I would like to see addressed. 1. scalability - it is unnecessarily awkward to have more than 2 levels of subclassing currently. Direct subclass of CAP uses cgi_init; child of subclass uses setup; anything else must call SUPER::setup. 2. a more fully developed lifecycle model - similar to the one that Apache itself uses. In particular, it would be really helpful to have explicit phases for state (e.g., Session munging), authentication, and authorization. I imagine those 3 in particular to be extremely helpful for building things like role based access control or single sign-on into your application. 3. a more fully developed plugin/event system; I think this goes along with #2 (i.e., a few more hooks), but in addition to this I have always thought it would be useful to have some sort of mechanism through which plugins might be able to query one another. A good example (and actually the main motivation for #2 and #3) are the CAP Authorization and Authentication plugins. The short list of troubles I have had with using these two are: * when used together, Authorization is called before Authentication, making it awkward to handle authorization errors of unauthenticated guests (or maybe Authz assumes an authenticated session); * default behavior of Authz is to query directly the Authorization plugin instance for a username; this works fine in that situation, but there is no clear way for plugin A to make information available to plugin B; That's just an example. I think that these improvements would go a long way to encouraging the timeless benefits that you've outlined about CAP above. 4. more flexibility with the query object...err response object; I've run into some hoops to jump through when I wanted to use CGI::Simple and be able to upload capabilities on or off in a sub class. 5. persistence - I would like to say that I'd like to learn more about CAP and the ecosystem in persistent environments. It's my impression that there are some corner cases or funny issues with it. I do not claim this is true, but I think that we can all agree that while persistent environments such as mod_perl are considered old fashioned, I think that they will prove remain relevant amist the tide of alternatives and "middleware" laden configurations. For me, the ultimate goal would be to use CAP to create a responsive and consistent daemon type application as served by Apache, defined strictly through things like runmodes, plugins, etc. Is PSGI the path to this? Maybe, maybe not. 6*. the last mile - in application frameworks, I am unsure of any that take the finite state machine model to its logical max. This thought may be way out there, but defining things like runmodes only takes you so far. Going a step further, perhaps done through more feature dispatching or routing, it'd be really nice to be able to define the application runmodes in terms of a transition function (e.g., current runmode, input, resulting runmode). In otherwords, support defining an application to the fullest extent possible though some sort of runmode dispatch table annotations. *(forgive me this one is "out there", and I still have not sat down to figure out what such a capability would look like or value it would actually add) Brett > > Thanks, > > Mark > > > ##### CGI::Application community mailing list ################ > ## ## > ## To unsubscribe, or change your message delivery options, ## > ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > -- Register Now for cPanel Conference Oct 8-10, 2012, Houston, Texas http://conference.cpanel.net/ ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: CGI::Application status update from the maintainer
by Ron Savage
::
Rate this Message:
Hi Brett
I'm snipping this email because I expect to pen several replies. On 06/09/12 03:57, B. Estrade wrote: > Thank you, Mark. Responses are inlined. >> - A "::Compat" addition that allows people to keep using a maximal >> amount of the old API if they need to. (Including a certain amount of >> plugins) Changing the API and keeping a back-compat API means not changing the API in the (new) back-compat part of the code. This is always a difficult decision. My basic feeling is if people stick with the (new) back-compat API they might as well have stuck with the old (back-compat!) API. So the question is, why not switch to the new API. Perhaps because some people want to switch in small steps. My policy is that if the switch is on, commit to the whole of the new API. > Or maybe just do something like how perl5 turns on new version based > features (e.g., use CGI::Application q/1.2.3/;). > >> >> - PSGI-native. I'm excited that Perl web frameworks are converging here. >> We'll be able to take advantage of PSGI "Middleware" that was designed >> with other frameworks in mind. Many things that were CGI::App plugins >> before are now better done done as PSGI "Middleware". As a plugin >> author, you get the benefit of having more users who may be using >> other frameworks. The difference with CGI::App will be that PSGI will >> the *only* code path supported. > > Nice. I already use Plack::Middleware::(ContentLength, Session and Static), in various situations, when using CGI::Snapp. You do realize that's possible, right? > I would like to warn that traditional persistent environments will > continue to remain relevant, and I think it's a mistake to discount > this. Absolutely. My policy is to make available tools for all programmers, not just those who adopt the latest mechanism. After all, there is always going to be a pool of programmers whose work environment and/or personality is too conservative to let them be amongst the first to switch. They may in fact make that switch years after the leaders to. Or, any of us may be employed to support old code. > Additionally, from what I have seen from the other frameworks, nothing > solves anything in principle beyond what CAP does. Some make it easier > to define runmodes or to set up dispatching, but you still need to > properly create a proper MVC separation and set of supporting modules. > It's the same amount of work no matter what you use. This is a marvellous point. I've looked a Mojo a number of times, but despite its great cleverness, it's major use seems to be smart switching of requests. Likewise, there are now quite a new routing-oriented packages available. They all attack the same problem, but it's a small part of a whole app. And the classic CGI::Application::Dispatch (copied to CGI::Snapp::Dispatch) is a beautifully simply way to do that. >> - Uses Any::Moose / Mouse. I endorse the Moose API and Mouse brings >> much of that API to lower resource environments, like the CGI >> environment where CGI::Application has always performed well. This is tricky. Why is the env low-resourced? And if it is, what's wrong with targeting it with a low-overhead env such as non-Moose? >> It's already possible to write a CGI::App subclass based on Moose or >> Mouse, but like with PSGI, I think it's in our best interest to >> upgrade to first class support. > > I am not sure what this buys anyone, to be frank. I know that using Me neither. For control freaks it obviously gives greater, er, control, over parameters and attributes, but that alone does not guarantee great apps. > these object layering might incite some sort of religious war. > Ultimately, this decision is clearly in the hands of those who do the > work. I have my reservations about moving away from Perlish idioms > and towards the oop flavors of the week. Any core might be well served > by avoiding any sort of meta object sugar over the long haul. > > I think my overall point is that CAP and what it provides is timeless. > The pendulum swings both ways, and it would be nice to see CAP focus > on improving its strengths and not trying to do what the other kids > might be doing. > >> >> Just as "PSGI Middleware" presents a new opportunity for code re-use, >> Moose/Mouse "roles" present another alternative to "plugins" that can >> be shared between frameworks. For example, methods for logging, >> database access and "config" data are all good candidates to be >> implemented as roles. This is important. See: - Class::Method::Delegate (no dependencies [actually Carp], no bugs) - Role::Tiny (ditto [actually Exporter], 1 bug) - Role::Basic (Storable, 3 bugs) - Moo::Role (various, 2 bugs) - Moose::Role (ditto, 52 bugs) But see what Role::Tiny has to say about Role::Basic. So Moose/Mouse are not actually needed, if smallness is a virtue. >> - Templating APIs removed from core, for now. We'll get a new templating >> API, although the details are still TBD. Yep. >> - Plans to replace CGI.pm with request and response objects. As the >> CGI.pm maintainer, I could devote another full post to reasons why I >> don't to be using it in another 5 or 10 years. Details here are still >> to be determined as well. This is important, and probably why moving to PSGI should be considered if not done sooner rather than later. > I think I am not really clear on what change in perspective means. Is > it truly a semantic change or is it just a different name? I am > somewhat familiar with some of the other new fangled frameworks, but > not well enough to know what the difference is between this > request/response versus query objects. In brief, the CGI way has been re-thought and replaced. The end result is just request/response of course (what else could it be?), but done again with the knowledge of years of experience with CGI. >> - The popular and small "::Forward()" and "::Redirect()" plugins will >> be merged into the core. Good idea. > It would be really nice to merge in some bare bones Authentication and > Authorization support - maybe ever by more fully developing CAP's lifecycle. Likewise. It's a pity a standard(!) way of doing this with CAP doesn't seem to have evolved /with the approval of all/. > Here are some items I would like to see addressed. > > 1. scalability - it is unnecessarily awkward to have more than 2 > levels of subclassing currently. This statement worries me. Could you please expand. Also, did you look at CGI::Snapp::Demo::Four::Wrapper, which easily wraps CGI::Snapp::Demo::Four. It's specifically a (simple) demo of sub-classing. > Direct subclass of CAP uses cgi_init; child of subclass uses setup; > anything else must call SUPER::setup. How does this differ from any other class which uses sub-classing? The parent method is either completely overridden or called /and/ partially overridden. Or am I missing something? > 3. a more fully developed plugin/event system; I think this goes along > with #2 (i.e., a few more hooks), but in addition to this I have > always thought it would be useful to have some sort of mechanism > through which plugins might be able to query one another. A good > example (and actually the main motivation for #2 and #3) are the CAP > Authorization and Authentication plugins. The short list of troubles > I have had with using these two are: > > * when used together, Authorization is called before Authentication, > making it awkward to handle authorization errors of unauthenticated > guests (or maybe Authz assumes an authenticated session); > > * default behavior of Authz is to query directly the Authorization > plugin instance for a username; this works fine in that situation, > but there is no clear way for plugin A to make information available > to plugin B; There's no doubt they are awkward. I'd argue the underlying CAP structure is sound, and just this part need a bug re-think. > 4. more flexibility with the query object...err response object; I've > run into some hoops to jump through when I wanted to use CGI::Simple > and be able to upload capabilities on or off in a sub class. It'd help if you could expand on this issue. > 5. persistence - I would like to say that I'd like to learn more about CAP and > the ecosystem in persistent environments. It's my impression that > there are some corner cases or funny issues with it. I do not claim > this is true, but I think that we can all agree that while persistent > environments such as mod_perl are considered old fashioned, I think > that they will prove remain relevant amist the tide of alternatives and > "middleware" laden configurations. For me, the ultimate goal would be > to use CAP to create a responsive and consistent daemon type > application as served by Apache, defined strictly through things like runmodes, > plugins, etc. Is PSGI the path to this? Maybe, maybe not. I only use plack (dev) and starman (prod), but I used to use Apache(2)::Registry, with CAP. Is that what you're referring to. Is there something specific which needs to be added? > 6*. the last mile - in application frameworks, I am unsure of any that > take the finite state machine model to its logical max. This thought > may be way out there, but defining things like runmodes only takes you > so far. Going a step further, perhaps done through more feature dispatching > or routing, it'd be really nice to be able to define the application > runmodes in terms of a transition function (e.g., current runmode, > input, resulting runmode). In otherwords, support defining an > application to the fullest extent possible though some sort of runmode > dispatch table annotations. Perhaps you need Mojo after all :-)). > *(forgive me this one is "out there", and I still have not sat down to > figure out what such a capability would look like or value it would > actually add) On the contrary - many thanx. We need all ideas to be put out there....... -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: CGI::Application status update from the maintainer
by estravd
::
Rate this Message:
Snipped
On Thu, Sep 06, 2012 at 09:12:40AM +1000, Ron Savage wrote: > Hi Brett > > It would be really nice to merge in some bare bones Authentication and > > Authorization support - maybe ever by more fully developing CAP's lifecycle. > > Likewise. It's a pity a standard(!) way of doing this with CAP doesn't > seem to have evolved /with the approval of all/. > > > Here are some items I would like to see addressed. > > > > 1. scalability - it is unnecessarily awkward to have more than 2 > > levels of subclassing currently. > > This statement worries me. Could you please expand. > > Also, did you look at CGI::Snapp::Demo::Four::Wrapper, which easily > wraps CGI::Snapp::Demo::Four. It's specifically a (simple) demo of > sub-classing. > > > Direct subclass of CAP uses cgi_init; child of subclass uses setup; > > anything else must call SUPER::setup. > > How does this differ from any other class which uses sub-classing? The > parent method is either completely overridden or called /and/ partially > overridden. Or am I missing something? What I mean is that there are 2 methods that basically do the same thing. If you have MyApp (ISA CGI::Application), you would initialize runmodes and whatnot via cgiapp_init. Say you subclass MyApp to get MyApp::Foo, but want to keep what is going on in MyApp::cgiapp_init; but you have your own specific MyApp::Foo runmodes. You'd most cleanly do this by defining MyApp::Foo::setup. Now, what if you want to subclass MyApp::Foo into MyApp::Foo::Derp, but you have some Derp specific runmodes. You end up having to redefine cgiapp_init or setup; in either case, you're going to have to make an explicit call to SUPER::cgiapp_init or SUPER::setup. You're limited to 2 generations below CAP if you want to subclass without explicitly calling on SUPER because you have 2 explicit methods -cgiapp_init and setup. I am suggesting a way to provide any number of generations without having to call on SUPER. Here is my real world use case. I split my applications into 2 parts; one amounts to the UI payload delivery, basically HTML that makes all calls asynchronously. The other is strictly non-UI and handles only asynchronous requests (i.e., the "REST" API). And I typically have this hierarchy: 1. WebCommon.pm (ISA CGI::Application; implements Authentication and common run modes) 2. WebApp.pm (ISA WebCommon; base class for the UI delivery or initial "view") 3. WebAPI.pm (ISA WebCommon; base class for the "REST" API) >From there, I may have another or even another 2 levels of WebApps or WebAPIs. In WebCommon.pm, I define cgiapp_init; in WebApps.pm and WebAPI.pm, I define a setup. Beyond that, I redefine setup with a call to $self->SUPER::setup - not something I really like doing. > > > 3. a more fully developed plugin/event system; I think this goes along > > with #2 (i.e., a few more hooks), but in addition to this I have > > always thought it would be useful to have some sort of mechanism > > through which plugins might be able to query one another. A good > > example (and actually the main motivation for #2 and #3) are the CAP > > Authorization and Authentication plugins. The short list of troubles > > I have had with using these two are: > > > > * when used together, Authorization is called before Authentication, > > making it awkward to handle authorization errors of unauthenticated > > guests (or maybe Authz assumes an authenticated session); > > > > * default behavior of Authz is to query directly the Authorization > > plugin instance for a username; this works fine in that situation, > > but there is no clear way for plugin A to make information available > > to plugin B; > > There's no doubt they are awkward. I'd argue the underlying CAP > structure is sound, and just this part need a bug re-think. > > > 4. more flexibility with the query object...err response object; I've > > run into some hoops to jump through when I wanted to use CGI::Simple > > and be able to upload capabilities on or off in a sub class. > > It'd help if you could expand on this issue. I want to use CGI::Simple, but do not want to enable uploads app-wide. I have a subclass (WebAPI::UploadApp, say) where I do want to enable uploads. In WebCommon.pm, I have to do this: our $cgi; #= CGI::Simple->new; sub cgiapp_get_query { use CGI::Simple (); $cgi = CGI::Simple->new(); return $cgi; } Then in order to override that CGI::Simple to enable uploads, in WebAPI::UploadApp, I have to do this: sub cgiapp_get_query { my $self = shift; use CGI::Simple (); $CGI::Simple::DISABLE_UPLOADS = 0; $self::SUPER::cgi = CGI::Simple->new(); return $self::SUPER::cgi; } Granted, there is probably a more correct, cleaner, or better way to do this; if so, I am all ears. > > > 5. persistence - I would like to say that I'd like to learn more about CAP and > > the ecosystem in persistent environments. It's my impression that > > there are some corner cases or funny issues with it. I do not claim > > this is true, but I think that we can all agree that while persistent > > environments such as mod_perl are considered old fashioned, I think > > that they will prove remain relevant amist the tide of alternatives and > > "middleware" laden configurations. For me, the ultimate goal would be > > to use CAP to create a responsive and consistent daemon type > > application as served by Apache, defined strictly through things like runmodes, > > plugins, etc. Is PSGI the path to this? Maybe, maybe not. > > I only use plack (dev) and starman (prod), but I used to use > Apache(2)::Registry, with CAP. Is that what you're referring to. Yes. > > Is there something specific which needs to be added? > I don't know :)...I plan on investigating persistent environments more in the near future. > > 6*. the last mile - in application frameworks, I am unsure of any that > > take the finite state machine model to its logical max. This thought > > may be way out there, but defining things like runmodes only takes you > > so far. Going a step further, perhaps done through more feature dispatching > > or routing, it'd be really nice to be able to define the application > > runmodes in terms of a transition function (e.g., current runmode, > > input, resulting runmode). In otherwords, support defining an > > application to the fullest extent possible though some sort of runmode > > dispatch table annotations. > > Perhaps you need Mojo after all :-)). Maybe so. > > > > *(forgive me this one is "out there", and I still have not sat down to > > figure out what such a capability would look like or value it would > > actually add) > > On the contrary - many thanx. > > We need all ideas to be put out there....... Thanks :) Brett > > -- > Ron Savage > http://savage.net.au/ > Ph: 0421 920 622 > > ##### CGI::Application community mailing list ################ > ## ## > ## To unsubscribe, or change your message delivery options, ## > ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > -- Register Now for cPanel Conference Oct 8-10, 2012, Houston, Texas http://conference.cpanel.net/ ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: CGI::Application status update from the maintainer
by Rhesa Rozendaal-2
::
Rate this Message:
On 09/06/2012 04:48 PM, B. Estrade wrote:
> You're limited to 2 generations below CAP if you want to subclass > without explicitly calling on SUPER because you have 2 explicit > methods -cgiapp_init and setup. I am suggesting a way to provide any > number of generations without having to call on SUPER. You're not limited to 2 levels of inheritance. The grandchild's SUPER calls the child's method, and the child's SUPER calls the parent's method. It'll work the same even when you add a grandchild. (At some point I'd start asking myself if inheritance is really the way I'd want to structure my application). > Here is my real world use case. I split my applications into 2 parts; > one amounts to the UI payload delivery, basically HTML that makes all > calls asynchronously. The other is strictly non-UI and handles only > asynchronous requests (i.e., the "REST" API). And I typically have > this hierarchy: > > 1. WebCommon.pm (ISA CGI::Application; implements Authentication and common run modes) > 2. WebApp.pm (ISA WebCommon; base class for the UI delivery or initial "view") > 3. WebAPI.pm (ISA WebCommon; base class for the "REST" API) > >>From there, I may have another or even another 2 levels of WebApps or > WebAPIs. In WebCommon.pm, I define cgiapp_init; in WebApps.pm and > WebAPI.pm, I define a setup. Beyond that, I redefine setup with a call > to $self->SUPER::setup - not something I really like doing. You'd be better off setting up your runmodes in an init hook. That's the way I do it in CA::Plugin::RunmodeDeclare. package WebCommon; use base 'CGI::Application'; __PACKAGE__->add_callback( init => sub { $_[0]->run_modes([ ... ]); }); package WebAPI; use base 'WebCommon'; __PACKAGE__->add_callback( init => sub { $_[0]->run_modes([ ... ]); }); package WebAPI::Stuff; use base 'WebAPI'; __PACKAGE__->add_callback( init => sub { $_[0]->run_modes([ ... ]); }); Then WebAPI has all the run modes of WebCommon, as well as its own run modes. And WebAPI::Stuff has those of WebAPI and its own. However, I'd ask myself if I really want to have all those parent run modes in the child app. > I want to use CGI::Simple, but do not want to enable uploads app-wide. > I have a subclass (WebAPI::UploadApp, say) where I do want to enable > uploads. > > In WebCommon.pm, I have to do this: > > our $cgi; #= CGI::Simple->new; Don't do this. You need a query object that's an attribute of the current CA object. A package variable is going to have too wide a scope. > sub cgiapp_get_query { > use CGI::Simple (); > $cgi = CGI::Simple->new(); > return $cgi; > } This is better written as: sub cgiapp_get_query { use CGI::Simple; return CGI::Simple->new; } > Then in order to override that CGI::Simple to enable uploads, in > WebAPI::UploadApp, I have to do this: > > sub cgiapp_get_query { > my $self = shift; > use CGI::Simple (); > $CGI::Simple::DISABLE_UPLOADS = 0; > $self::SUPER::cgi = CGI::Simple->new(); > return $self::SUPER::cgi; > } That code makes little sense. cgiapp_get_query is supposed to return a CGI compatible object. It's not supposed to change variables in another package. This is what you should do instead: sub cgiapp_get_query { local $CGI::Simple::DISABLE_UPLOADS = 0; return $_[0]->SUPER::cgiapp_get_query; } > Granted, there is probably a more correct, cleaner, or better way to do > this; if so, I am all ears. The only ugly thing about that is that package variable to influence upload behavior. It'd be prettier if CGI::Simple had an accessor for that, or a constructor argument. That's what you get for trying to be compatible with CGI.pm I guess ;) rhesa ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
|
|
Re: CGI::Application status update from the maintainer
by Ron Savage
::
Rate this Message:
Hi Brett
On 07/09/12 00:48, B. Estrade wrote: > What I mean is that there are 2 methods that basically do the same > thing. If you have MyApp (ISA CGI::Application), you would initialize > runmodes and whatnot via cgiapp_init. Say you subclass MyApp to get > MyApp::Foo, but want to keep what is going on in MyApp::cgiapp_init; > but you have your own specific MyApp::Foo runmodes. You'd most cleanly > do this by defining MyApp::Foo::setup. Now, what if you want to > subclass MyApp::Foo into MyApp::Foo::Derp, but you have some Derp > specific runmodes. You end up having to redefine cgiapp_init or > setup; in either case, you're going to have to make an explicit call > to SUPER::cgiapp_init or SUPER::setup. > > You're limited to 2 generations below CAP if you want to subclass > without explicitly calling on SUPER because you have 2 explicit > methods -cgiapp_init and setup. I am suggesting a way to provide any > number of generations without having to call on SUPER. Rhesa has replied with one (slightly more complex) way of doing things. Here is another: package WebCommon; use base 'CGI::Application'; sub cgi_init # or setup { $self -> web_common_init; } package WebAPI; use base 'WebCommon'; sub cgi_init # or setup { $self -> web_api_init; } package WebAPI::Stuff; use base 'WebAPI'; sub cgi_init # or setup { $self -> web_api_stuff_init; } The 3 new subs can be stand-alone or call each other or call common code. They can do whatever you think best. The point is that the sub-class cgi_inits are overridden by the /normal/ operation of CAP, and hence are called at the appropriate time /automatically/. Obviously you can call SUPER::cgi_init or SUPER::anything if you wish. (Sometimes of course calling a super class's method is mandatory. For instance, with CGI::Snapp, a sub-class must call SUPER::_init($arg), as in the demo. But that's to initialize object-level variables, having nothing to do with what we're talking about.) The problem is that SUPER::* is a way of sharing /all/ the code in the super class's cgi_init. If you don't wish to do that, then do as I've indicated above, and just share none or some of the code via web_common_init etc. You really do have a variety of ways to work. Lastly, there is no limit on the depth of nesting possible. -- Ron Savage http://savage.net.au/ Ph: 0421 920 622 ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################ |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
