SvenDowideit at home
Apr 29, 2008, 12:55 AM
Post #9 of 16
(398 views)
Permalink
|
|
Re: Proposal to the Perl Foundation for CatalystX::Installer
[In reply to]
|
|
Paul,
Is there a good reason why you're making a Catalyst specific 'generic
GUI web deployment module'?
Would it not be more useful to make a generic Web deployment and
configuration module that has a Catalyst personality (and thus allows
for others)?
Of course, I'm somewhat biased, as I don't 'just' use Catalyst. but it
does feel to me like you're missing out on a bigger opportunity that may
be not much more work - as I would expect you need to have a web UI that
works before Catalyst is up & running, that then can bootstrap and
configure the needed pre-requisites.
and then I can leverage your work for TWiki too :}
Sven
On Tue, 2008-04-29 at 00:56 -0500, Paul Cain wrote:
> I made the suggested changes to this proposal; below is the diff of
> the new versions and the old. I plan on submitting this in about 19
> hours.
>
> Any questions/comments are welcome.
>
>
> --- old_proposal.txt 2008-04-29 00:47:31.000000000 -0500
> +++ Perl_Foundation_Proposal.txt 2008-04-29 00:48:06.000000000 -0500
> @@ -1,187 +1,83 @@
> 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.
> -
> +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.
> +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, there is no accepted framework for
> providing GUI installers for catalyst applications; this module
> intends to provide a generic GUI for common web application use-cases,
> and a basis for extension where required. 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".
>
> +*Project Details*
> +For CatalystX::Installer, the Movable Type setup wizard is used as an
> inspiration for its design. The main new idea of this approach is that
> the program will provide a generic GUI that works with most common
> use-cases for Catalyst applications, and provides a framework for
> extension for specialist use-cases.
> +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 either:
> +1. adding the file script/myapp_setup.pl to the template for Catalyst
> programs. For example:
> + $ catalyst MyApp
> +
> + That command would create all of the files that it currently
> creates, plus "script/myapp_setup.pl".
> +2. Having the installer script running seperately such as:
> + $ catalyst MyApp
> + $ cd MyApp
> + $ catalystx-installer [options]
> +
> + Where "$ catalystx-installer [options] " creates
> script/myapp_setup.pl and handles any special options.
> +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
> server. 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',
> + '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.
> +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:
> +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.
> +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. When the GUI setup is
> complete, it will ask the user if they want the setup program to
> create a script that can be used to automatically enter the data that
> they just entered into the GUI setup program. This allows a user to
> clone a setup for multiple systems and of course a password is still
> required. Also, the script, if created, will only be readable by the
> user who created it.
>
> +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 17 – Feedback gathered – Begin designing class heirarchy charts,
> flowcharts, and other planning materials
> +
> +June 1 – Project Begins by starting coding on all necessary APIs for
> both the base program and user extensions
>
> -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 in the APIs
>
> -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 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 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.
> -
> -
> +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
>
> On Mon, Apr 28, 2008 at 11:57 AM, Paul Cain <fat.perl.hacker[at]gmail.com> wrote:
> > What if rather than having command line options, you could just use
> > WWW::Mechanize to automatically fill out the forms with a script.
> >
> > Something like:
> >
> > use WWW::Mechanize;
> > my $mech = WWW::Mechanize->new();
> >
> > #Your password shouldn't be hardcoded into a script this way in practice
> > $mech->submit_form(
> > fields => {
> > username => 'admin',
> > password => 'mypass',
> > }
> > );
> >
> > $mech->submit_form(
> > fields => {
> > dbd => 'sqlite',
> > dbname => 'foo.db',
> > #ect
> > },
> > );
> >
> > This would be easier than implementing two seperate interfaces for the
> > command line and GUI, and with a little golf it could probably be done
> > in a few perl -e commands.
> >
> >
> >
> > On Mon, Apr 28, 2008 at 2:14 AM, Kieren Diment <diment[at]gmail.com> wrote:
> > >
> > > On 28 Apr 2008, at 16:57, Andreas Marienborg wrote:
> > >
> > >
> > > >
> > > > On Apr 28, 2008, at 7:26 AM, Zbigniew Lukasiak wrote:
> > > >
> > > >
> > > > > On Mon, Apr 28, 2008 at 3:13 AM, Kieren Diment <diment[at]gmail.com> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > dunno about that. You could override the myapp_install.pl script so
> > > that
> > > > > > if @ARGV is not empty it runs it from the command line:
> > > > > >
> > > > > > script/myapp_install.pl --dsn dbd:sqlite:dbname=foo.db
> > > --admin-user=fred
> > > > > > --admin-passwd=wilma --deployment-path=/ and so on.
> > > > > >
> > > > >
> > > > > Hmm. My understanding was that all of the options above could be
> > > > > entered in the GUI.
> > > > >
> > > >
> > > > I think Kieren wants to be able to do BOTH, and that the
> > > CatalystX::Installer, in the end of the process, gives you a command line
> > > equivalent of the setup you already did, if, for instance, you want to redo
> > > the installation later or something like that
> > > >
> > >
> > > Yes, exactly, thanks :-)
> > >
> > >
> > >
> > > _______________________________________________
> > > Catalyst-dev mailing list
> > > Catalyst-dev[at]lists.scsys.co.uk
> > > http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
> > >
> >
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev[at]lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
|
