[cgiapp] CGI::Application status update from the maintainer

[Bill Stephenson]

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.