fat.perl.hacker at gmail
Apr 7, 2008, 12:46 AM
Post #1 of 3
(311 views)
Permalink
|
|
2nd Draft Proposal for the Generic GUI for installing Catalyst Apps(CatalystX::Installer)
|
|
Here is the second draft of my proposal for the Generic GUI for installing
Catalyst Apps, which I have decided to call CatalystX::Installer.
Thanks to everyone who provided feedback on my first draft.
Again, questions/comments/etc are welcome.
*Paul Cain*
*fat.perl.hacker[at]gmail.com*
*CatalystX::Installer – A generic GUI deployment for catalyst applications*
*Abstract*
A web application that provides a cross-platform generic GUI for setting up
Perl applications.
*Benefits to the Perl/Open Source Community*
Anyone who wants a friendly GUI with which they can have a 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 program intends to help standardize setup
by providing a generic GUI for all or most of them. 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 program, 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 applications that are 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.
Since there are several ways to do this project, I will illustrate two
possible solutions.
The first 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 standard GUI design to get
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 then
customize this based on the requirements of his or her application. I would
create a set of APIs 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 make sure all of the dependencies
are installed(and prompts the user if not). Next, it verifies that the
program runs correctly by doing the tests. After that, it can display the
GUI setup, get the information, create a configuration file in a chosen
format, and install.
The second solution involves having a dist-file from CatalystX::Installer
in the server's root directory and myapp_setup.pl in the cgi-bin. The
advantage here is that existing Catalyst applications do not need to be
modified in order to use CatalystX::Installer. The server administrator can
install the module on his server and then use it to install existing
Catalyst applications. The server administrator can then do something like:
$ perl myapp_setup.pl catalysty_app.tar.gz
What this would do is extract the application to a temporary location(/tmp
on *nix, or B:\Users\paul\AppData\Local\Temp on Windows), check the
dependencies in Makefile.PL and prompt the user if they are missing, run the
application's tests to verify that it works correctly, display the GUI, get
the configuration information, write that information to a file in a chosen
format, and install. The server administrator could also customize
CatalystX::Installer's form in the way described earlier if he or she so
chose to.
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.
Snags, unforeseen difficulties, and setbacks can and do occur in almost
every programming project. One common Perl saying is, "There's more than one
way to do it." One thing that I will try if I run into problems is to take a
different approach to solving the problem. If I still have problems, I will
consult my mentor for help on the problem. I also plan on building up my
arsenal of debugging aids/tools to help squash any bugs that slip into my
program.
If, despite my best effort, everything does not work exactly as
planned, the code will still be of some use. For example if I am unable to
create a program that is generic enough to work with all Catalyst
applications, it will still be usable as a setup wizard for some Catalyst
applications.
*Project Schedule*
-
May 26 – Project Begins
-
Monday, June 9 – Alpha 1 released – APIs for the basic program are
complete
-
Monday, June 30-- Alpha 2 released – User extension APIs are complete
-
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
*References and Likely Mentors*
Marcus Ramberg was the one who originally suggested this idea to me on the
psoc mailing list.
Eric Wilherm and Kieren Diment helped me to refine my ideas and proposal.
Also, I took the name suggested by Kieren.
*License*
This program is licensed under the same terms as Perl itself.
*Bio*
My name is Paul Cain. I am 18 years old and I am a Freshman(sophomore by the
time that GSOC 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.
*Eligibility*
I meet all the Google Summer of Code requirements and have the paperwork to
prove it.
|
