[Catalyst-dev] Proposal to the Perl Foundation for CatalystX::Installer

[Paul Cain]

Here a draft of my proposal to the Perl Foundation for
CatalystX::Installer. I've made quite a few revisions since the last
version.

Comments are welcome.




Paul Cain

fat.perl.hacker at gmail.com

CatalystX::Installer – A generic GUI deployment for catalyst applications



*Synopsis*
Create a web application that provides a cross-platform generic GUI
for setting up Catalyst applications. There is no command line version
of this program since anyone who wants to use the command line can
just edit the configuration files directly.



*Benefits to the Perl Community*
Anyone who wants a friendly GUI with which they can easily setup,
test, and automatically configure their catalyst applications will
benefit from this project.
The target user base for this application is people who would like to
simplify and automate the installation of Catalyst applications onto
their web servers. Currently, each Catalyst application uses its own
setup wizard(if it even has one); this module intends to help
standardize setup by providing a generic GUI for all or most of them.
There is no command line version of this program since anyone who
wants to use the command line can just edit the configuration files
directly. I think this program could be classified as a new approach
that is also an aggregation of existing tools and ideas.



 *Deliverables *
I plan to deliver a completed Perl module, called
CatalystX::Installer, that provides a generic GUI for the deployment
of Catalyst applications.



*Project Details *
For CatalystX::Installer, Marcus suggested that something like the
setup wizard for Movable Type would be a place to start for a design.
The main new idea of this approach is that the program will provide a
generic GUI that works with most if not all Catalyst application
installed on a system.
This approach frees the Catalyst developers from having to design a
setup wizard for their application(with the possible exception of some
special cases) while also freeing the user from the hassle of having
to use a different(or no) install wizard for each Catalyst application
that he or she installs.

The solution involves adding the file "script/myapp_setup.pl" to the
template for Catalyst programs. For example:

$ catalyst MyApp

would create all of the files that it currently creates, plus
"script/myapp_setup.pl". The file would contain a stand-alone server
similar to script/myapp_server.pl. The administrator could then
connect to this server and use the GUI to apply the configuration
information(such as database info, fastcgi information, mod_perl,
server address, login information, language, etc) when the application
is installed on a sever. The application developer could also
customize this based on the requirements of his or her application. I
would create a set of APIs that wrap around HTML::FormFu to make this
process as simple as possible. For example, if the developer wanted to
add an entry to get the preferred type of configuration file(YAML,
INI, XML, etc), he or she could add some code similar to this to
"script/myapp_setup.pl".

my $preferred_config_type=CatalystX::Installer::Forms::SelectionList->new();
$preferred_config_type->add({
     'YAML' => "YAML",
     'INI' => 'Windows INI File',
     'XML' => 'XML',
});

This would allow the developer to easily customize the installer for
his or her applications. A link to "script/myapp_setup.pl" can be
placed into the root directory during make dist.

When the user(server administrator) downloads the applications, she
first extracts it, switches to directory, and then types the command:

$ perl myapp_setup.pl

It then starts by checking Makefile.PL to verify that all of the
dependencies are installed. If all dependencies are not met, it asks
the user if he or she wants to automatically install the CPAN
dependencies, and also warns about any missing non-CPAN dependencies
that cannot be installed. Next, it verifies that the program runs
correctly by doing the tests. After that, it runs make install. When
make install completes, it will prompt the user to either enter a
password or use a randomly generated password with which the GUI setup
can be accessed(the user can change the password in the GUI setup).
The user can then access this server either from the local machine or
a remote one, as long as they are using web browser capable of
entering information into web forms. The password exists to prevent
unauthorized access to myapp_setup.pl, it is stored in an encrypted
location, and it is required for all subsequent runnings of
myapp_setup.pl. The connection will also be encrypted with SSL/TLS in
order to assure the safety of all data sent.

CatalystX::Installer can be used for more than just installation; it
can also be used to reconfigure an application that has already been
installed. For example, if the user were to run myapp_setup.pl again,
they could change the options they set up the first time.
myapp_setup.pl would then save a backup copy of the original config
file(s), and create new ones with the new options.

There are of course some uncertainties for this application. One of
the main foreseeable problems for this application will be making the
GUI generic enough where works for all programs, but not so generic
that user or developer(s) needs to do a lot of customizations in order
to satisfactorily setup the program.
I plan on doing some surveys on the Catalyst mailing list to see
exactly what options people want myapp_setup.pl to have by default.

*Project Schedule*
May 10 – Gather community feedback about what they want in the the module

May 17 – Feedback gathered – Begin designing class heirarchy charts,
flowcharts,  all necessary modules, and other planning materials

May 26 – Project Begins by starting coding on all necessary APIs for
both the base program and user extensions

Monday, June 18 – APIs are functional – Begin programming
myapp_setup.pl to perform its necessary functions and fixing any
unforeseen problems with the APIs

Monday, July 7 – Beta 1 released – All features exist now in the
program; program will be distributed to any willing victims for
testing

Monday, July 21 – Beta 2 released – mainly just bug fixes

Monday, August 4th – Release Candidate 1 released

August 11 – Release Candidate 2 released – This release may be skipped
if no show-stopping bugs are found in RC1

August 18 – Project goes gold




*Bio*
My name is Paul Cain. I am 18 years old and I am a Freshman(sophomore
by the time summer starts) and I go to Kansas State University at
Salina, where I have a 4.0 GPA.
I have been programming in Perl for about 2.5 years and I have read
several books on programming in Perl. Of those books, Perl Best
Practices was my favorite. I've been using Linux since 2004, although
right now I do most of my work on Windows Vista with ActivePerl and
Strawberry Perl.
For development tools, I started out using Activestate's ActivePerl as
my Perl interpreter, but more recently I have been using Strawberry
Perl due to its superior CPAN compatibility. I've also used standard
Perl installation on various Linux distributions over the years. When
coding Perl, I usually use a text editor with syntax highlighting such
as Notepad++, Kate, or Gedit. However, the larger my code gets, the
harder it is to manage with a simple text editor, especially when to
code reaches 1000+ lines. I plan to switch to an IDE with a class
browser, automated debugger, and other tools that will make the code
easier to manage. Finally, I use dual-17 inch monitors in order to
increase my productivity.

Generally I try to stay close to the coding standards set forth in
Perl Best Practices because they provide a logical way to code that
can be easily duplicated among multiple developers. For this
particular project, I think that an Object-Oriented method of program
design would probably be the best design method due to the size,
complexity, and type of the program.

Most of the Perl programs I write are pretty short, but the largest
program I've written was a personal project that ended up being about
1800 lines of code, much of which was for the GUI behavior. This
particular program particular will most likely be larger than that,
but I plan to use well-designed classes and strict adherence to Perl
Best Practice's coding standards in order to keep my code cleaning,
readable and easy to manage.



*Amount Requested*
$3000