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

[Mark Stosberg]

>
> 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