Front page | perl.beginners.cgi |
Postings from September 2010
Re: [cgiapp] Why perl lost steam...
Thread Previous
|
Thread Next
From:
Bill Stephenson
Date:
September 23, 2010 00:42
Subject:
Re: [cgiapp] Why perl lost steam...
Message ID:
71190bd21c7787727801b9c43e200875@ezinvoice.com
On Sep 22, 2010, at 5:53 PM, Ron Savage wrote:
> Your preference to hark back to perhaps obsolete software strongly
> suggests your need to rethink the bases of your decision-making ideas.
Probably. Or just get out of the game entirely.
But hear me out because this post contains some beginner's questions...
I've been working on an iDevice web app lately. It's a small, focused,
app. I made it with CGI.pm, no other perl modules, and the Prototype JS
libraries.
This little app uses the CGI->save method to store user preferences on
the server. Now, since the file the preferences are stored in is named
the same as the user's username the app knows right where to find it,
and CGI.pm loads their data into an object pretty darn quickly. This
probably is easier to code, and probably requires less processing power
than using any SQL database engine for apps that have a user base of up
to 100k users, maybe even more.
I am wrong about that?
Which is faster and/or more efficient, this:
sub get_prefs {
if (-e "./users/$user") {
open(my $FILE, "./users/$user);
$PREFS = new CGI($FILE);
close $FILE;
}
else {&error_page("Opps...")}
}
or however you'd do the same with MySQL?
I really don't understand how loading that data into a CGI.pm object
could be done more efficiently by firing up a database engine or even
making a query to one that's sitting there running all the time. That
has to require more of something, doesn't it?
My interest in peeking at Boulder was really OT, but let me explain a
little more about why it intrigues me. It seems to offer some simple
ways to search for data in sets of simple data files like those created
when using the CGI->save method, almost an SQL like way of retrieving
data from this format. And HTML5 supports a client side data storage
function that uses the same format, so the two should be easily shared
and synced between the client and server. And it may be worth looking
into how the functionality of Boulder might be recreated with JS for
the client side.
I would offer that there is a difference between something being
obsolete and being ignored. Certainly when Mr. Stein created "Boulder"
he was aware that MySQL existed. What was his motivation? Is Boulder
still being used to suit those purposes and more? If so, it's not
really obsolete is it?
And I am certainly not arguing that CGI::App and other Frameworks are
not appropriate for small apps, what I am thinking is there may be a
good reason for a simpler, ultralight, framework for small apps to
exist.
I suppose most of the functionality of that framework I imagine already
resides in CGI.pm. I just don't think it's been integrated into an
approach that's easy for beginners to excited about.
For me, creating my first "iPhone" web app has been a fun and exciting
experience and I see an opportunity for perl, as a language and the
community as a whole, to benefit from the momentum of mobile apps. Read
what Jann Linder wrote in his blog about his experience creating his
first native iPhone app:
iPhone Programming Hell :: http://www.jann.com/
Compared to Jann, and everyone that's responded here, I am, and always
will be, just a perl beginner. But my app did not require native iOS
code or a SQL database engine, so were my decision making ideas for my
approach really flawed?
I'll readily admit that some of my code may have flaws, but I need to
understand more about why my approach is before I rethink it.
Thanks to all that have responded,
Bill
Thread Previous
|
Thread Next