Re: [cgiapp] CGI::Application status update from the maintainer
On Tue, Sep 18, 2012 at 12:19:46PM -0500, Bill Stephenson wrote: > On Sep 15, 2012, at 10:58 AM, Mark Stosberg wrote: > > > Most web clients support JSON now, which allows for more complex > > structures than the simple key/value pair that CGI.pm uses. > > > Mark, I think this is relevant to what I'm advocating here. > > That JSON support is accomplished with javascript parsing a string of JSON > data that is stored in the localStorage key/value format. I think that's a > very clever use of the localStorage feature because it extends the > functionality without adding complexity. > > Here's an interesting article on that: > > https://hacks.mozilla.org/2012/03/there-is-no-simple-solution-for-local-storage/ > > That article points out the value of the simplicity in having the > localStorage function and the key/value format, and also how the IndexedDB > feature is not so simple. So, I'm not at all alone in seeing the benefits of > these simple to use functions and this format. That simplicity is really > quite ingenious, and I think this is what's important to keep in mind. > > What developers are doing with localStorage and JSON on the client side is > really not any different in concept than storing a string of JSON data with > CGI.pm's save function on the server side. I think that sounds pretty handy. > > Here's a quote from the author about that: > > "This local storage solution has a few very tempting features for web > developers: > > ? It is dead simple > ? It uses strings for storage instead of complex databases (and you can > store more complex data using JSON encoding) ..." > > In that article the author, Chris Heilmann, also discusses how unforeseen > uses of the localStorage feature have revealed issues with how it is > implemented. He offers several ideas on how to deal with those issues and he > concludes his findings with "We need to fix this". > > It seems to me that we are in a somewhat similar situation, but are leaning > towards a "We need to ditch this" conclusion. > > As I've said, my reasons for advocating for this feature are selfish. I am > not qualified to help implement it so how can they be anything but selfish? > But, that does not mean others will not also benefit. I think the example of > creative and clever usage discussed above helps to demonstrate that. > > While I may not be able to help implement the feature, I might be able to > help with example code and documentation, and I'd be more than willing to try. > > Kindest Regards, It is unclear to me exactly what feature you're advocating, even though I went back and read the previous threads. I'd like to point out that while it doesn't matter what the client or the server do, the defacto standard is to send key/value pairs to the server no matter what the HTTP method is. CGI.pm will happly parse a k/v string sent via POST just as it would sent via GET; however, if you send just JSON to the server, you must manually parse whatever is in the POSTDATA field. That's my experience anyway. It'd be nice to have something on the server that recognized the JSON as natively as a k/v query string, particularly for non-GET methods. Also, YUI 3 has some interesting local storage options. Brett > > Bill > > > # 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: [cgiapp] CGI::Application status update from the maintainer
On Sep 15, 2012, at 10:58 AM, Mark Stosberg wrote: > Most web clients support JSON now, which allows for more complex > structures than the simple key/value pair that CGI.pm uses. Mark, I think this is relevant to what I'm advocating here. That JSON support is accomplished with javascript parsing a string of JSON data that is stored in the localStorage key/value format. I think that's a very clever use of the localStorage feature because it extends the functionality without adding complexity. Here's an interesting article on that: https://hacks.mozilla.org/2012/03/there-is-no-simple-solution-for-local-storage/ That article points out the value of the simplicity in having the localStorage function and the key/value format, and also how the IndexedDB feature is not so simple. So, I'm not at all alone in seeing the benefits of these simple to use functions and this format. That simplicity is really quite ingenious, and I think this is what's important to keep in mind. What developers are doing with localStorage and JSON on the client side is really not any different in concept than storing a string of JSON data with CGI.pm's save function on the server side. I think that sounds pretty handy. Here's a quote from the author about that: "This local storage solution has a few very tempting features for web developers: • It is dead simple • It uses strings for storage instead of complex databases (and you can store more complex data using JSON encoding) ..." In that article the author, Chris Heilmann, also discusses how unforeseen uses of the localStorage feature have revealed issues with how it is implemented. He offers several ideas on how to deal with those issues and he concludes his findings with "We need to fix this". It seems to me that we are in a somewhat similar situation, but are leaning towards a "We need to ditch this" conclusion. As I've said, my reasons for advocating for this feature are selfish. I am not qualified to help implement it so how can they be anything but selfish? But, that does not mean others will not also benefit. I think the example of creative and clever usage discussed above helps to demonstrate that. While I may not be able to help implement the feature, I might be able to help with example code and documentation, and I'd be more than willing to try. Kindest Regards, Bill # 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: [cgiapp] CGI::Application status update from the maintainer
On 09/15/2012 05:00 PM, Jiří Pavlovský wrote: > On 15.9.2012 3:22, Mark Stosberg wrote: >> Regarding performance, I recently benchmarked accessor generation time >> for Moo vs Mouse vs Moose vs manual accessors (what CGI::App uses) and >> raw hashes. In a persistent environment like you are using Moose was >> generating 162,999 accessers *per second* on my laptop. I suspect that >> wouldn't be your botteneck. :) This was only marginally slower than >> the "manual accessors" benchmark, which would be close to >> CGI::Application, delivering 187,617 accessors per second. >> https://raw.github.com/gist/3431863/bf6ecdbe23ea8f97a316b2f4ac1fa211cf48ce86/gistfile1.pl > > Thanks for the benchmark. Help me understand the results. Is it really > so that Moose is on par with the "manual accessors" while Mouse is an > order of magnitude faster? > And Moo order of magnitude slower? > I'm using Moose a lot, but now I'll have a look at Mouse for sure. That's my reading of it. The source code is is there if you want to check the details of what's going on. Of course, the benchmark doesn't simulate a full application. Within a complete real-world application, it's not clear to me how much accessor speed would matter compared to other factors. 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: [cgiapp] CGI::Application status update from the maintainer
On 15.9.2012 3:22, Mark Stosberg wrote: > Regarding performance, I recently benchmarked accessor generation time > for Moo vs Mouse vs Moose vs manual accessors (what CGI::App uses) and > raw hashes. In a persistent environment like you are using Moose was > generating 162,999 accessers *per second* on my laptop. I suspect that > wouldn't be your botteneck. :) This was only marginally slower than > the "manual accessors" benchmark, which would be close to > CGI::Application, delivering 187,617 accessors per second. > https://raw.github.com/gist/3431863/bf6ecdbe23ea8f97a316b2f4ac1fa211cf48ce86/gistfile1.pl Thanks for the benchmark. Help me understand the results. Is it really so that Moose is on par with the "manual accessors" while Mouse is an order of magnitude faster? And Moo order of magnitude slower? I'm using Moose a lot, but now I'll have a look at Mouse for sure. -- 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: [cgiapp] CGI::Application status update from the maintainer
On Sep 15, 2012, at 10:41 AM, Mark Stosberg wrote: > I stated to look at the code, but I didn't get very far until I ran into > this notice: > > # Do not read, copy, distribute, execute, run, or use > # this code without express written permission from > # William H. Stephenson. > > At that point, I was compelled to immediately close the file and stop > reading. I apologize, that's in a template I set up years ago in BBEdit, I'll remove it. I'll point out that since I put the link to the code there and invite you to use it, that is permission, still, I'll remove it as it really was an oversight. (Actually, it's a joke. It invokes a chuckle in me because it is so ridicules knowing I'm the only one that ever reads and executes my code and most wouldn't want it anyway and I wouldn't lose anything if they took it. You must have thought that too, didn't it make you chuckle just a little bit?) > I see. I hope that $note_path and $notepad_number are handled > appropriately, so that a user can't end up overwritting unintended file > son our file system. They are hard coded in a set-up file. > Using a representation of an HTTP response as a data storage and > retrieval system makes me shudder. "Shudder"? ( :D ) Why? How do you actually avoid that? I understand that in a publicly shared space you have to filter that input, so that's what you do, as best as you can. But do other modules process that same input differently somehow? Does CGI.pm handle it poorly and in a manner that cannot be addressed? You have to use that same data no matter what, so what makes you shudder? > HTML::Template has a feature called 'associate' which makes this kind of > pass-through easier: Well now, that's just magic! Thanks for pointing that out, I'll give it a spin this evening. And thanks again for listening. I know you're busy... Bill # 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: [cgiapp] CGI::Application status update from the maintainer
> > I know that you're right according to common practice, so I have to > admit it made me laugh reading that this morning for that very reason. > > But... in my (weak) defense, in chapter three, page 119, of Lincoln's > book, "The official guide to programming with CGI.pm" is the "Advanced > Trick" that explains "Saving State to Files", and that's all I'm > really doing here, and nothing more, so I think it's not really > accurate to say that how I'm using CGI.pm was never envisioned or > intended, or if that's truly the case, I've already explained why it > may work now when it may not have when the book was written. As software ages, some features lose favor. We end up with books like "Perl Best Practices" which advise completely ignoring some features, of Perl and "JavaScript: The Good Parts", which does the same for JavaScript. There may have been a time when it was considered a good practice to use CGI.pm for data persistence. It is no longer the case. > If we look at web apps designed to run on mobile devices, that are by > design pretty simple and tightly focused, than this simple and basic > approach to handling data might be a very valuable option. Both Android and iOS have official SQLite support and APIs. Android's demo application for using SQLite is a Notepad. http://developer.android.com/reference/android/database/sqlite/SQLiteDatabase.html >The data format CGI.pm uses is already supported by most web clients, >so a way to take advantage of that compatibility make sense to me. Most web clients support JSON now, which allows for more complex structures than the simple key/value pair that CGI.pm uses. > These are a few of the things I ponder when I think about and explore > frameworks. Thank you for your thoughts. 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: [cgiapp] CGI::Application status update from the maintainer
Bill--
> I've sort of taken my own path to create web apps, and while it works for me,
> I've gotten some blowback for it a few times over the years, but I really
> don't mind that, so I'll explain it.
>
> I have a small demo "Note Pad" app at www.raspberryperl.com:
>
> app -> http://raspberryperl.com/cgi-bin/NoteApp/notes.cgi
> code -> http://raspberryperl.com/NoteAppCode/
I stated to look at the code, but I didn't get very far until I ran into
this notice:
# Do not read, copy, distribute, execute, run, or use
# this code without express written permission from
# William H. Stephenson.
At that point, I was compelled to immediately close the file and stop
reading.
> When a user creates a note I save the data in a file:
>
> open(my $NOTE, "> $note_path/$notepad_number")
> or &Note_home("Error 3: That didn't work");
> $cgi->save($NOTE);
> close $NOTE;
I see. I hope that $note_path and $notepad_number are handled
appropriately, so that a user can't end up overwritting unintended file
son our file system.
> When they want to view or edit a note I load the data into a CGI object:
>
> $NOTE = new CGI($FILE); # Throw out the old $NOTE, replace it with a
> new one
> close $FILE;
> return ($NOTE);
Using a representation of an HTTP response as a data storage and
retrieval system makes me shudder. Someone here has already suggested
using XML instead. A format like XML or JSON would offer some greater
flexibility.
I would also suggest considering a DBI backend, such as DBD::CSV,
DBD::AnyData or DBD::SQLite2. This way, your code is a good position to
"scale up" to using a full SQL database if that's ever desired, and you
have a standard set up tools and techniques to use between large
projects that use SQL and your smaller projects too.
I've done a lot of small projects with CGI::Application, and I set a
fairly low bar before I start to involve a SQL database.
Even on low-cost shared hosting accounts, SQL databases are readily
available.
>
> And use HTML:Template to display it:
>
> $template->param(note_subject => $cgi->param('note_subject'));
HTML::Template has a feature called 'associate' which makes this kind of
pass-through easier:
https://metacpan.org/module/HTML::Template#Miscellaneous-Options
> I generally use the epoch time of creation to name the file. This gives me an
> easy way to search by date for documents.
>
> 1344045036.txt
>
> Or perhaps assign a document number:
>
> 0001.txt
Either scheme might work well, until you have a lot of documents and
need to search by some other key, requiring opening *every* file to
check something.
> In that case, if you know the document number, finding and loading the
> data is incredibly fast because you're using the system's b-tree to
> locate it. The trick (if it can be called that) is creating a unique
> directory for each user so the app knows where to find their
> documents. Put each different document type in a unique sub-directory
> and you've really narrowed down where to find what you're looking for.
>
> Now, my logic for this being practical is that for the most part
> database engines were designed to solve just a few problems:
>
> 1. Slow processors took a long time ripping through a bunch of files
> while searching for a specific piece of data.
> 2. RAM was expensive and a lack of enough RAM made managing large
> numbers of files impractical and limited what an OS could support.
> 3. Hard Drive space was expensive, so storing a bunch of files was
> also expensive.
>
> But now, RAM and ROM is comparatively cheap, and processors and OSs
> are way faster than they were 15 years ago, so this approach keeps
> becoming more practical for some applications. In my case, the users
> of the apps I build will never create hundreds of thousands of files.
> Ten thousand would be the upper ends of what they'd ever create, so
> this actually works pretty good, and it's very simple to build and
> maintain.
I thought the beauty of SQL was that you expressed *what you wanted*,
not *how to make it happen*.
I much prefer that to code that open and closes files, scans content
line by line, and greps for values.
But I agree with the overall sentiment that the best tools for complex
projects are often not the same as the best tools for small projects.
> I use a flexible interpretation of a MVC design approach in my apps,
> and it would seem to me that if there were ever a necessity to move to
> a SQL database it should be fairly easy to change the routines to get
> and put data, and to load the existing data into the database. If
> that's the case, then my approach might be useful for RAD (rapid
> application development) if nothing else.
It sounds like you've thought about how you might scale up if you needed
to.
> For my own sake, what I am trying to do is limit complexity. Not at
> all costs, but I do set a high bar for the returns. Complexity, in my
> opinion and ex
Re: [cgiapp] CGI::Application status update from the maintainer
>> I would generally plan to keep the core small, but would welcome more
>> full-featured stacks to be shipped that were based on it, as Titanium
>> did for CGI::Application.
>
> My motivation for this is based on our needs. We use CAP to write not
> just authenticated applications, but those with role based
> authorization. I have had moderate success using Authen and Authz,
> but in order to do what was necessary to Authen before Authz or to
> properly scale out the RBAC restrictions, I had to ditch both and
> implement my own callbacks during the prerun stage. I suppose both
> plugins got be over the learning curve, and after I was able to
> implement authentication and authorization without the plugins.
>
> The one trouble I had with Authen and Authz is that while Authz will
> call the Authen::username method if this plugin is being used, my
> experiences lead me to believe that Authz will get called no matter if
> there is an authenticated username or not - leading to having to
> handle the case of username == undef. In otherwords, failure to
> authenticate is not triggered before Authz is attempted (thus, this
> has to be handled outside of Authen by Authz)...does this make sense?
>
> I tried to order the plugins so that Authen failed before Authz was
> attempted, but I couldn't figure out how to do this cleanly. I feel
> like this is a serious problem.
My major project also uses Authentication and Authorization. I use and
enjoy CGI::App's Authorization plugin, but found the Authentication
plugin too cumbersone vs rolling my own, so I took the ideas from it,
and implemented my own check at the prerun stage to see if the user is
authenticated. It looks something like this (pseudo-code):
Maybe the key part is that I configure the 'Authz' plugin, so that if
authorization fails, they are redirected to authenticate.
$self->authz('shelter_state')->config(
GET_USERNAME => ...,
FORBIDDEN_RUNMODE => 'redirect_to_login',
DRIVER => ...,
);
My "redirect_to_login" run mode looks like this:
sub redirect_to_login {
my $self = shift;
my $q = $self->query;
my $return_url = $q->self_url;
$return_url = $q->escape($return_url);
my $url = $self->cfg('ROOT_URL').'/account/login';
$self->redirect($url."?return_url=$return_url");
}
When the login process is done, we redirect the user back to where they
came from, and Authorization can be attempted again.
The Authenication and Authorization plugins were originally written the
same author, Cees Hek. I would be suprised to find the two plugins can't
be made to play nicely together.
Did you try re-ordering your "use" lines of the plugins to see if that
addressed your problem? Both the plugins register a callback at the
'prerun' stage when their 'import' method is called during 'use'.
Reversing the order of the 'use' lines will reverse the order they are
triggered in.
> Anyway, my main reason for recommending these 2 in particular as
> bona fide life cycle events is that the mirror Apache's life cycle.
And why is Apache's life cycle what we should be mirroring?
> I prefer it because it provided me with a significant epiphany after
> doing CGI the hard way for too long. It's also more or less what we
> standardize on internally at cPanel.
>
> We use it to write internal applications and external facing APIs that
> require both authentication and authorization. One of our primary
> requirements is also raw speed, so even .05 seconds matters to us.
> This is the basis for my distaste for any sort of MOP layer. However,
> I concede that in a persistent environment, start up times are
> amortized over the long term and in this way any cost eventually goes
> to 0.
It's interesting to hear that CGI::Application is a standard at cPanel!
Regarding performance, I recently benchmarked accessor generation time
for Moo vs Mouse vs Moose vs manual accessors (what CGI::App uses) and
raw hashes.
In a persistent environment like you are using Moose was generating
162,999 accessers *per second* on my laptop. I suspect that wouldn't be
your botteneck. :) This was only marginally slower than the "manual
accessors" benchmark, which would be close to CGI::Application,
delivering 187,617 accessors per second.
https://raw.github.com/gist/3431863/bf6ecdbe23ea8f97a316b2f4ac1fa211cf48ce86/gistfile1.pl
Since your application is performance-sensitive, I would be interested
to know where your profiling shows your performance bottlenecks to be.
Database access? Templating? I suspect the answer won't be in whether
your web framework is using Any::Moose or not.
>> Note that the Moose API also helps here as well, as it allows you to say
>> this:
>>
>> # Add some additional functionality after 'setup' runs in the parent
>> after 'setup' => sub {
>> my $self = shift;
>> };
>
> Thank you. Yeah, that syntax makes me cring actually :).
>
> However, this out of the bo
Re: [cgiapp] CGI::Application status update from the maintainer
On Sep 13, 2012, at 12:02 PM, Jerry Kaidor wrote: >> Hi Bill, >> >> This is fascinating, but I think you're abusing CGI.pm for something >> it was never intended for. > > *** Which is one of the glories of open source. Things keep getting used > for stuff that the original writers never envisioned. I know that you're right according to common practice, so I have to admit it made me laugh reading that this morning for that very reason. But... in my (weak) defense, in chapter three, page 119, of Lincoln's book, "The official guide to programming with CGI.pm" is the "Advanced Trick" that explains "Saving State to Files", and that's all I'm really doing here, and nothing more, so I think it's not really accurate to say that how I'm using CGI.pm was never envisioned or intended, or if that's truly the case, I've already explained why it may work now when it may not have when the book was written. I'd like to offer a few more things to consider... The OS's native file system is really a database too, and a pretty powerful one, so it seems logical to me that before you start looking to add another layer on top of the OS to manage data you should ask if you have a good reason. I think it's fair to say that this is a question that most frameworks forget to ask when they build their foundation. They assume you're going to want and need a SQL database. I think an option to use a very simple data format is a worthy one. I think that out of the box, a framework should provide a means to do what I did with that demo. I should not have to use SQL to create an app. (of course, that's entirely selfish, and I don't expect anyone to feel at all compelled to accommodate that.) If we look at web apps designed to run on mobile devices, that are by design pretty simple and tightly focused, than this simple and basic approach to handling data might be a very valuable option. The data format CGI.pm uses is already supported by most web clients, so a way to take advantage of that compatibility make sense to me. If we consider that we're now at a point where we can include a computer with the software we create (as opposed to the other way around that it's always been) then using the native OS file system offers opportunities that we shouldn't overlook. Your software owns that entire file system now, it's the only thing that will be using it. The big buzz right now is all about cloud computing, but web app builders have been doing that for a long time now and we know the downsides. The future, as far as I can see forward, looks to me like one where users can have a computer dedicated on site that runs the same app as one they have on a cloud (our web apps) and the user can choose where their data resides, on site, on a cloud, or a combination of both. It has to go this way because we all know that clouds can burst and computers that will run our web apps are getting incredibly cheap and small, so using them both together is the future (well, according to me anyway ) If that's where we're going than we need something to make it easy for the end user to customize their own software. Something so simple that most anyone can do it, or hire someone to do it. This also provides a market for software we make because if our software is simple enough for the end user to modify they have good reason to buy it. Complexity from the start shoots that model in both feet, but as an option it extends the value greatly. These are a few of the things I ponder when I think about and explore frameworks. # 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: [cgiapp] CGI::Application status update from the maintainer
> Hi Bill, > > This is fascinating, but I think you're abusing CGI.pm for something > it was never intended for. *** Which is one of the glories of open source. Things keep getting used for stuff that the original writers never envisioned. - Jerry Kaidor # 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: [cgiapp] CGI::Application status update from the maintainer
Hi Bill,
This is fascinating, but I think you're abusing CGI.pm for something
it was never intended for.
How about using XML::Simple to encode the data and write that into the
flat files?
# Grab a hashref of data from the posted form
my $data = $cgi->Vars;
# Dump data into file
XMLout($data, OutputFile => $filename);
...
# read data from file
my $data = XMLin($filename);
# use HTML::Template to display it
$template->param(%$data);
etc
On 12 September 2012 19:16, Bill Stephenson wrote:
>> There not yet specific plans for how CGI.pm will be replaced. How do you
>> use the save/restore feature?
>
> Thank you, Mark. I appreciate your taking my concerns under consideration.
>
> I've sort of taken my own path to create web apps, and while it works for me,
> I've gotten some blowback for it a few times over the years, but I really
> don't mind that, so I'll explain it.
>
> I have a small demo "Note Pad" app at www.raspberryperl.com:
>
> app -> http://raspberryperl.com/cgi-bin/NoteApp/notes.cgi
> code -> http://raspberryperl.com/NoteAppCode/
>
> When a user creates a note I save the data in a file:
>
> open(my $NOTE, "> $note_path/$notepad_number")
> or &Note_home("Error 3: That didn't work");
> $cgi->save($NOTE);
> close $NOTE;
>
> When they want to view or edit a note I load the data into a CGI object:
>
> $NOTE = new CGI($FILE); # Throw out the old $NOTE, replace it with a
> new one
> close $FILE;
> return ($NOTE);
>
> And use HTML:Template to display it:
>
> $template->param(note_subject => $cgi->param('note_subject'));
>
> I generally use the epoch time of creation to name the file. This gives me an
> easy way to search by date for documents.
>
> 1344045036.txt
>
> Or perhaps assign a document number:
>
> 0001.txt
>
> In that case, if you know the document number, finding and loading the data
> is incredibly fast because you're using the system's b-tree to locate it. The
> trick (if it can be called that) is creating a unique directory for each user
> so the app knows where to find their documents. Put each different document
> type in a unique sub-directory and you've really narrowed down where to find
> what you're looking for.
>
> Now, my logic for this being practical is that for the most part database
> engines were designed to solve just a few problems:
>
> 1. Slow processors took a long time ripping through a bunch of files while
> searching for a specific piece of data.
> 2. RAM was expensive and a lack of enough RAM made managing large numbers of
> files impractical and limited what an OS could support.
> 3. Hard Drive space was expensive, so storing a bunch of files was also
> expensive.
>
> But now, RAM and ROM is comparatively cheap, and processors and OSs are way
> faster than they were 15 years ago, so this approach keeps becoming more
> practical for some applications. In my case, the users of the apps I build
> will never create hundreds of thousands of files. Ten thousand would be the
> upper ends of what they'd ever create, so this actually works pretty good,
> and it's very simple to build and maintain.
>
> I've done tests on ripping through 5000 files (with an app like the demo
> linked above) to find a unique string in one or more files and the result
> times are not that bad. I suspect they'd be faster if I used ModPerl or
> FastCGI, but I deploy on a VPS so that's not been an option. My tests
> resulted in the initial search being a bit slow, but a second search is
> pretty fast, so I suspect Apache is cacheing some data but I really don't
> know much about how that works.
>
> I have some apps with several thousand users, and some with over 100,000
> files in the system. They all run on a VPS and they're pretty darn fast, so
> again, I'm not finding a compelling reason to move to a SQL database engine.
>
> I use a flexible interpretation of a MVC design approach in my apps, and it
> would seem to me that if there were ever a necessity to move to a SQL
> database it should be fairly easy to change the routines to get and put data,
> and to load the existing data into the database. If that's the case, then my
> approach might be useful for RAD (rapid application development) if nothing
> else.
>
> For my own sake, what I am trying to do is limit complexity. Not at all
> costs, but I do set a high bar for the returns. Complexity, in my opinion and
> experience, gets expensive fast. I think it's fair to point out that a SQL
> database engine may offer another point of entry for hackers to create
> mayhem. I'm not saying that my approach is more secure, but it seems to me
> that you must constantly be staying on top of issues specific to any database
> engine you're using, and that may create additional expense which may be
> unnecessary.
>
> I understand that if you must have a Relational database my approach may not
> work, but again, with the
Re: [cgiapp] CGI::Application status update from the maintainer
> There not yet specific plans for how CGI.pm will be replaced. How do you
> use the save/restore feature?
Thank you, Mark. I appreciate your taking my concerns under consideration.
I've sort of taken my own path to create web apps, and while it works for me,
I've gotten some blowback for it a few times over the years, but I really don't
mind that, so I'll explain it.
I have a small demo "Note Pad" app at www.raspberryperl.com:
app -> http://raspberryperl.com/cgi-bin/NoteApp/notes.cgi
code -> http://raspberryperl.com/NoteAppCode/
When a user creates a note I save the data in a file:
open(my $NOTE, "> $note_path/$notepad_number")
or &Note_home("Error 3: That didn't work");
$cgi->save($NOTE);
close $NOTE;
When they want to view or edit a note I load the data into a CGI object:
$NOTE = new CGI($FILE); # Throw out the old $NOTE, replace it with a
new one
close $FILE;
return ($NOTE);
And use HTML:Template to display it:
$template->param(note_subject => $cgi->param('note_subject'));
I generally use the epoch time of creation to name the file. This gives me an
easy way to search by date for documents.
1344045036.txt
Or perhaps assign a document number:
0001.txt
In that case, if you know the document number, finding and loading the data is
incredibly fast because you're using the system's b-tree to locate it. The
trick (if it can be called that) is creating a unique directory for each user
so the app knows where to find their documents. Put each different document
type in a unique sub-directory and you've really narrowed down where to find
what you're looking for.
Now, my logic for this being practical is that for the most part database
engines were designed to solve just a few problems:
1. Slow processors took a long time ripping through a bunch of files while
searching for a specific piece of data.
2. RAM was expensive and a lack of enough RAM made managing large numbers of
files impractical and limited what an OS could support.
3. Hard Drive space was expensive, so storing a bunch of files was also
expensive.
But now, RAM and ROM is comparatively cheap, and processors and OSs are way
faster than they were 15 years ago, so this approach keeps becoming more
practical for some applications. In my case, the users of the apps I build will
never create hundreds of thousands of files. Ten thousand would be the upper
ends of what they'd ever create, so this actually works pretty good, and it's
very simple to build and maintain.
I've done tests on ripping through 5000 files (with an app like the demo linked
above) to find a unique string in one or more files and the result times are
not that bad. I suspect they'd be faster if I used ModPerl or FastCGI, but I
deploy on a VPS so that's not been an option. My tests resulted in the initial
search being a bit slow, but a second search is pretty fast, so I suspect
Apache is cacheing some data but I really don't know much about how that works.
I have some apps with several thousand users, and some with over 100,000 files
in the system. They all run on a VPS and they're pretty darn fast, so again,
I'm not finding a compelling reason to move to a SQL database engine.
I use a flexible interpretation of a MVC design approach in my apps, and it
would seem to me that if there were ever a necessity to move to a SQL database
it should be fairly easy to change the routines to get and put data, and to
load the existing data into the database. If that's the case, then my approach
might be useful for RAD (rapid application development) if nothing else.
For my own sake, what I am trying to do is limit complexity. Not at all costs,
but I do set a high bar for the returns. Complexity, in my opinion and
experience, gets expensive fast. I think it's fair to point out that a SQL
database engine may offer another point of entry for hackers to create mayhem.
I'm not saying that my approach is more secure, but it seems to me that you
must constantly be staying on top of issues specific to any database engine
you're using, and that may create additional expense which may be unnecessary.
I understand that if you must have a Relational database my approach may not
work, but again, with the apps I've created I've not come across that need. So
I believe there are some good reasons to have a simple way, like that in CGI.pm
and CGI:Session to store and load data using files.
Kindest Regards,
Bill Stephenson
# 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: [cgiapp] CGI::Application status update from the maintainer
Hi Brett On 11/09/12 00:05, B. Estrade wrote: > I think what I was thinking of for a "more developed" plugin system is > to provide a way to better manage when plugins are fired wrt hooks. > > For example, have an "after" or "before" type of modifier when > registering a callback would be nice. Even better would be a way to > easily manage the handler queue associated with each hook. It's not > entirely clear to me how to ensure that handlerA will fire before > handlerB; I also know from reading the documentation that a class > level handler will fire before instance level handlers. This might be > by design or just a consequence of the implementation; however being > able to control the handler execution order would be useful I believe. I don't mind if you choose to continue with CGI::Application rather than switch to CGI::Snapp, but you should be aware that in the latter's documentation, I went to great lengths to spell out this matter. See/Read for yourself my explanation: https://metacpan.org/module/CGI::Snapp#The-Flow-of-Control HTH. -- 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: [cgiapp] CGI::Application status update from the maintainer
Thank you, Mark.
I accept what you so at face value and will seek to educate myself
more. Below I address the questions you asked me.
On Sat, Sep 08, 2012 at 06:10:55PM -0400, Mark Stosberg wrote:
>
snip..
> >
> > It would be really nice to merge in some bare bones Authentication and
> > Authorization support - maybe ever by more fully developing CAP's lifecycle.
>
> More detailed suggestions would be welcome here, but I'm hestitent. Are
> there examples of other frames that do something here in a way that's
> appealing?
Not that I know of; I must admit I am a one trick pony wrt frameworks.
CAP is all I use and know.
>
> I would generally plan to keep the core small, but would welcome more
> full-featured stacks to be shipped that were based on it, as Titanium
> did for CGI::Application.
My motivation for this is based on our needs. We use CAP to write not
just authenticated applications, but those with role based
authorization. I have had moderate success using Authen and Authz,
but in order to do what was necessary to Authen before Authz or to
properly scale out the RBAC restrictions, I had to ditch both and
implement my own callbacks during the prerun stage. I suppose both
plugins got be over the learning curve, and after I was able to
implement authentication and authorization without the plugins.
Anyway, my main reason for recommending these 2 in particular as
bona fide life cycle events is that the mirror Apache's life cycle. I
think this reflects the value of these two stages. The first
(authentication) is simply for verifying to some degree that the actor
on the system is who they claim to be; the authorization is to ensure
that this authentication actor has authorized to execute the targeted
run mode. Both are prerun type of stages, but first classing them
would be nice.
I am not sure I can persuade you to formalize these two stages in
particular, but I hope that you consider this. I believe that
authentication and RBAC style authorization is only going to become
more important, and if nothing these stages would provide a clue to
application programmers that CAP is very much suitable for industrial
strenght web applications.
>
> One project that strikes me as interesting here is "Abilities".
> It addresses the problem space by using a "role". It is framework
> independent, but is intended to be used as part of web applications.
>
> https://metacpan.org/module/Abilities
Thank you.
>
> This is an example of the kind of code I would like to make more easily
> available to CGI::App based projects.
>
> > I am a recent addition to this community, and prefer CAP well over the
> > other alternatives.
>
> That's good to hear, and welcome. Could you say more about why you
> prefer it and how you use it?
I prefer it because it provided me with a significant epiphany after
doing CGI the hard way for too long. It's also more or less what we
standardize on internally at cPanel.
We use it to write internal applications and external facing APIs that
require both authentication and authorization. One of our primary
requirements is also raw speed, so even .05 seconds matters to us.
This is the basis for my distaste for any sort of MOP layer. However,
I concede that in a persistent environment, start up times are
amortized over the long term and in this way any cost eventually goes
to 0.
>
> > 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.
>
> Another option I use sometimes is to use the callback system:
>
> # Register an action to happen at the init stage.
> __PACKAGE__->add_callback('init', sub {
>
> });
Nice.
>
> Note that the Moose API also helps here as well, as it allows you to say
> this:
>
> # Add some additional functionality after 'setup' runs in the parent
> after 'setup' => sub {
> my $self = shift;
> };
>
Thank you. Yeah, that syntax makes me cring actually :).
However, this out of the box seems to provide the basis for a very
well structured plugin system.
>
> https://metacpan.org/module/Moose::Manual::MethodModifiers#BEFORE-and-AFTER-modifiers
>
> The Moose API also provides "BUILD", which like our callback system is
> called for every class in the inheritance hierarchy. So another way to
> add some "initialization" functionality would be to put this in your
> Moose/Mouse based child class:
>
> # Another way to add extra functionality when setting up classes.
> sub BUILD {
> my $self = shift;
> }
>
> > 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 r
Re: [cgiapp] CGI::Application status update from the maintainer
Bill,
Thanks for feedback. Responses are below.
On 09/02/2012 01:46 PM, Bill Stephenson wrote:
> Hi Mark,
>
> Nice to hear you're going to move forward with the CAP project.
>
> After reading your comments about CGI.pm, and comments from others
> here, I'm left wondering about a few things. If you're ditching
> CGI.pm altogether I know that I'll have to as well.
>
> That's not going to be easy for me. I love the simplicity of these
> features:
>
> $cgi = new CGI;
> print $cgi->param('contact_name');
> $cgi->save($FILE);
> $cgi = new CGI($FILE);
>
> What will happen to them?
>
> The simple name=value data format used by the save routine is the same
> as the client side data storage in HTML5 (sessionStorage), and I like
> that it's easy to understand and read this format, and that I can use
> it on both ends (client/server) of my apps.
There not yet specific plans for how CGI.pm will be replaced. How do you
use the save/restore feature? I can say that the PSGI environment does
seem a good deal cleaner for dealing with "input". In CGI, the input by
default comes from STDIN (but large content like post requests), and
several environment variables. This makes the process a bit mysterious,
as well as being action-at-distance a source for confusion. For example,
if something has read and consumed STDIN, it may not there again for
something else to read.
With PSGI, the input is explicitly provided through a Perl hashref, and
the body content comes through a standard file handle.
While I haven't seen a implementation save/restore for PSGI request
objects, it strikes me that it would be pleasant to build.
> What will happen to CGI::Session?
>
> These are all simple, and easy, and familiar. Will the new project
> have these, or something similar?
Like CGI.pm, it will continue to exist, but over time I expect I will
quit using it myself and move on to something else.
Plack::Middleware::Session is an obvious choice to consider for this.
I expect I will personally want to use the "Pure SQL" approach to
session storage, so I will need to first write my own storage driver for
it.
I will appreciate moving away from something based on CGI.pm, towards
using another tool that is shared with other frameworks.
http://search.cpan.org/~miyagawa/Plack-Middleware-Session-0.15/lib/Plack/Middleware/Session.pm
https://metacpan.org/module/CGI::Session::Driver::pure_sql
Those who wish to remain with CGI::App / CGI.pm / CGI::Session are
welcome to do so, but will become responsible for more or all of the
maintenance of them.
> As far as I know, Catalyst, Dancer, and Mojolicious do not have the
> "save" and "new from file" routines, they use SQL and a third party
> database engine only. I know this is probably not something that most
> developers would miss, but I think it's pretty handy. I also think
> that it's a good place for beginners to start learning to use a
> framework. One can go a long way creating apps before they need an SQL
> database, and becoming proficient with SQL is expensive. For the apps
> I build it's like swatting a fly with a bulldozer.
I'm personally a big fan of SQL and think the related investment is well
worth it. I find the basics rather comprehenable:
"INSERT INTO table VALUES", \%values;
"UPDATE table SET",\%values;
"DELETE FROM table WHERE id = ",\$id;
"SELECT * FROM table WHERE id = ",\$id;
( The above syntax works with DBIx::Simple + SQL::Interp, my preferred
access method. )
However, Plack::Middleware::Session does support a file-storage backend:
https://metacpan.org/module/Plack::Session::Store::File
> Anyway, I also want to thank you for all you've done with CGI.pm and
> other modules I use everyday. I, like so many others, have been
> standing on your shoulders for years, and I want you to know that I
> really do appreciate what you've done for me. If you ever get down to
> the Ozarks all the beer and Skittles are on me!
>
> Kindest Regards,
>
> Bill Stephenson
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: [cgiapp] CGI::Application status update from the maintainer
Hi Mark On 09/09/12 10:28, Mark Stosberg wrote: > - 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? > > I'm thinking primarily of these environments: > >- CGI, used in shared hosting accounts where there is persistent option >- Automated tests, which like CGI, need to load modules each time. > > These environments also see non-persistent CGI::App use sometimes: > >- Cron scripts (I use CGI::App for cron scripts for convenience) >- Interactive command-line scripts (I also use CGI::App for some of > these which are part of a large website). OK. Good points. > I'm not thinking so much in terms hardware. A few years ago I > benchmarked the start-up times of various Perl-based web building tools, > which would apply to the environments above: > > > http://mark.stosberg.com/blog/2008/11/startup-benchmarks-for-mojo-catalyst-titanium-httpengine-and-cgiapplication.html > > Since then, hardware has gotten faster, and SSDs are becoming more > common. Today I benchmark "Mouse" taking .05 seconds to load on my > laptop. That's price I think is completely reasonable to pay. Without > using a timing tool, the difference in indistinquishable from "instant". Agreed: .05 sec is nothing. > time -p perl -MMouse -e 1 > >>> 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. > > I also see that CGI.pm has over 80 open bugs, while > Plack::Request/Plack::Response appear to have 2 open bugs in the Plack > bug queue that apply to them, with both them appearing to be enhancement > requests. > > The number of bug reports a project has seems to often be driven by > popularity. There's also a certain accumulation that comes with age. > The comparison above is misleading in any case, as as the "small" role > solutions have just one module or so in the distribution, so those bugs > are exactly about roles. The Moose bug queue is for the whole Moose > project. Only about 5 or 6 that I see have "role" in the title of the > bug reports. > > Also consider that CGI.pm has one person committing fixes for the 80+ > bugs (for lack of interest from others, it seems), while the Moose > project appears to have about 8 maintainers. > > On it's own, I don't think the general presence of bugs in a bug queue > presents a great concern about the quality of project, although specific > bugs certainly could. Are there specific bugs with Moose or Mouse roles > that you find troubling? Nope. I did not intend the # of bugs to say anything about the relative merits of the modules. It was all about (potential) user education. IMHO Role::Tiny looks like the best choice. -- 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: [cgiapp] CGI::Application status update from the maintainer
>>> - 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? I'm thinking primarily of these environments: - CGI, used in shared hosting accounts where there is persistent option - Automated tests, which like CGI, need to load modules each time. These environments also see non-persistent CGI::App use sometimes: - Cron scripts (I use CGI::App for cron scripts for convenience) - Interactive command-line scripts (I also use CGI::App for some of these which are part of a large website). I'm not thinking so much in terms hardware. A few years ago I benchmarked the start-up times of various Perl-based web building tools, which would apply to the environments above: http://mark.stosberg.com/blog/2008/11/startup-benchmarks-for-mojo-catalyst-titanium-httpengine-and-cgiapplication.html Since then, hardware has gotten faster, and SSDs are becoming more common. Today I benchmark "Mouse" taking .05 seconds to load on my laptop. That's price I think is completely reasonable to pay. Without using a timing tool, the difference in indistinquishable from "instant". time -p perl -MMouse -e 1 >> 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. I also see that CGI.pm has over 80 open bugs, while Plack::Request/Plack::Response appear to have 2 open bugs in the Plack bug queue that apply to them, with both them appearing to be enhancement requests. The number of bug reports a project has seems to often be driven by popularity. There's also a certain accumulation that comes with age. The comparison above is misleading in any case, as as the "small" role solutions have just one module or so in the distribution, so those bugs are exactly about roles. The Moose bug queue is for the whole Moose project. Only about 5 or 6 that I see have "role" in the title of the bug reports. Also consider that CGI.pm has one person committing fixes for the 80+ bugs (for lack of interest from others, it seems), while the Moose project appears to have about 8 maintainers. On it's own, I don't think the general presence of bugs in a bug queue presents a great concern about the quality of project, although specific bugs certainly could. Are there specific bugs with Moose or Mouse roles that you find troubling? 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: [cgiapp] CGI::Application status update from the maintainer
Brett, Thanks for the feedback. >> - 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/;). My goal there is to really start fresh, and have a minimal amount of extra stuff in the core. No one is being forced to upgrade, and changing a single line of code seems reasonable for those who want to upgrade the module without updating any of their other project code. >> - 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. I assume you mean mod_perl and FastCGI? PSGI helps code to run in those environments in a clean way. In those cases, it's definitely preferable to the old way of having framework code that includes conditionals for each environment. The guts of CGI.pm are an example of that ugliness. > 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. I disagree that it's the same amount of work no matter what choices you make. Some are easier to install, some are easier to learn, and some have more formality that provide ready-made discipline to help organize more complex projects. >> - 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 appreciate the frankness. :) > 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. Moose was first released over six years ago, so I don't think it's fair to call it's popularity weekly. With Any::Mouse, performance is good in CGI environments via Mouse, and also good in persistent environments with Moose. We've now reached a "Moose tipping point" where a project of any significant size is likely to be loading Moose or Mouse or Moo anyway, so whether to load them or not has become last of an issue. For example, if you want to access Amazon APIs via Perl, you'd likely choose Net::Amazon::S3, which loads Moose. If you use the modern Text::XSlate templating system, you'll be loading Mouse. If you want to conveniently access cookies in Test::WWW::Mechanize than you might use HTTP::CookieMonster, which loads Moo. Importantly, there's no requirement to use these in your own modules, or even switch from CGI::Application to the new project. > 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. I agree that there are timeless basic principles in there. I appreciate PSGI and the Moose APIs because there are helping bring the Perl web development community together by providing good options for re-using code between frameworks, with PSGI Middleware and Moose roles. >> - 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 >> desig
Re: [cgiapp] CGI::Application status update from the maintainer
Richard, Thanks for the feedback. > 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. I think each has it's own strengths. I looked at Mojo particularly closely, contributing doc and test patches along the way as I studied it. ( I was surprised to find that my contribution is still third highest by number of commits, although I haven't contributed since 2009: https://github.com/kraih/mojo/graphs/contributors ). In some ways their is convergance towards PSGI and Moose. I think that's a good thing, because there is now more re-use between frameworks. There's also more competition now among "lightweight" frameworks. Besides the one you mentioned, there is Web::Simple and Amon2, among many more less well known frameworks. I think CGI::App's basic design with stages and callbacks is worth carrying forward. I think a lightweight impementation of the Moose API is also worth supporting in the core, which is absent in Ron's fork. Finally, I think quite a number of people deployed CGI::Application and some of it's many plugins, and some of them like me would like a way forward to modernize their systems without a complete rewrite. > 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". I agree that dispatching has been central to web frameworks. By "global dispatching" I mean centralized dispatching-- having one place in your app to see all the URLs and what they app to. I call the default Cataylst style "local" dispatching-- placing the URIs that encompass the system next to the methods they map to. I like the design of CGI::Application::Dispatch::PSGI and don't currently have specific intents to change it. I've come across one other routing solution that appealed to me. Router::Simple has a nice OO syntax that's similar to what we use: https://metacpan.org/module/Router::Simple Amon2 then provides a nice DSL wrapper around it, so the resulting dispatch entries look like this: package MyApp::Web::Dispatcher; use Amon2::Web::Dispatcher::RouterSimple; connect '/' => 'Root#index'; connect '/my/'=> 'My#index'; connect '/my/:action' => 'My'; https://metacpan.org/module/Amon2::Web::Dispatcher::RouterSimple > Still, best wishes for C::A mark II if you decide to go through with it, 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: [cgiapp] CGI::Application status update from the maintainer
Thank you, Rhesa. This is helpful.
My last common on cgiapp_init and setup will be this. It's not simply
how deeply inheritance can be, it's the fact that there are 2 explicit
API methods for initializing an instance beyond what is provided for
in the ancestor. For me, it'd make more sense to do a way with setup
altogether and use a method similar to the init hook you mentioned
below. I am sure MMWV, but I will take your advice below. Thanks for
the help.
Brett
On Thu, Sep 6, 2012 at 12:04 PM, Rhesa Rozendaal wrote:
> 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: [cgiapp] CGI::Application status update from the maintainer
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/ ##
####
Re: [cgiapp] CGI::Application status update from the maintainer
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: [cgiapp] CGI::Application status update from the maintainer
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;
$sel
Re: [cgiapp] CGI::Application status update from the maintainer
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 t
Re: [cgiapp] CGI::Application status update from the maintainer
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" i
Re: [cgiapp] CGI::Application status update from the maintainer
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 me
Re: [cgiapp] CGI::Application status update from the maintainer
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: [cgiapp] CGI::Application status update from the maintainer
>> 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: [cgiapp] CGI::Application status update from the maintainer
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: [cgiapp] CGI::Application status update from the maintainer
On Wed, Aug 29, 2012 at 6:27 AM, Mark Stosberg 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/ ## ####
