fat.perl.hacker at gmail
May 21, 2008, 3:15 PM
Post #13 of 19
(647 views)
Permalink
|
My grant application for the Perl Foundation was rejected.
On Sat, May 17, 2008 at 5:24 AM, Paul Cain <fat.perl.hacker[at]gmail.com> wrote:
> I have created a rough specification based on all of this input. It is
> a bit rough right now, but I will try to clean it up when I get more
> time. This week is the week of my final exams, therefore I was busy.
>
> Here is the specification(if you are too lazy to read the whole thing,
> skip to the footnotes for points of conversation). Questions,
> comments, and more input/feedback are welcome:
>
>
> *Synopsis*
> Create a web application that provides a cross-platform generic GUI
> for setting up Catalyst applications.
>
> *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.
>
> #What The Developer Does
>
> $ catalyst MyApp
> $ cd MyApp
> $ catalystx-installer [options]
>
> The first command creates the skeleton of the Catalyst application,
> the second command switch to the root directory of that Catalyst
> application, and the third command creates script/myapp_setup.pl and
> handles any special options.
>
> Where script/myapp_setup.pl would contain a stand-alone server
> similar to script/myapp_server.pl. The administrator(person installing
> the Catalyst application) could then connect to this server and use
> the GUI to apply the configuration information[1] 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 application
> developer wanted to allow users to run SQL commands(from a file) on a
> SQLite database, he or she could do something like this[2].
>
> my $sql_commands=CatalystX::Installer::Controller->new();
> $sql_commands->set_type('Entry');
> $sql_commands->set_action(sub{
> my ($self, $c,$database,$sql_file);
> system "sqlite3 $database < $sql_file";
> });
>
> This would allow the developer to easily customize the installer for
> his or her applications. A link to "script/myapp_setup.pl" could
> possibly be placed into the root directory during make dist. The
> developer could place post-setup in a directory called
> 'post_t/'.Lastly, the developer could archive the application for
> distribution.
>
>
>
> #What The User Does
>
> When the user(server administrator) downloads the applications, they
> first extract it from the archive, switches to directory, and then
> types the command[3]:
>
> $ perl script/myapp_setup.pl
>
> First, it scans for dependencies with Module::ScanDeps, and adds any
> dependencies not already found in Makefile.PL to Makefile.PL. It then
> runs through the installation scripts while keeping the user informed
> of its progress:
>
> $perl Makefile.PL
> $make
> $make test
> $make install
>
> If the tests in 'make test' pass and 'make install' complete
> successfully, 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.
>
> The GUI setup will be (possible) be organized into four sections:
> Login, Model, Controller, and View. Each of these sections can also
> have sub-sections.
>
> 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
> configuration file(s), and create new ones with the new options[4].
>
> 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.
>
>
> #Footnotes
> [1] Some things that can be configured in the GUI setup include the following:
> username
> password
> plugins to load
> include file
> include paths
> database location(if exists)
> database schema
> Configuration for other types of models
> SQL commands
> Engine(mod_perl, fastcgi, ect)
> Extra configuration(any other editing of configuration files)
>
> [2] The final code will most likely be much different and much more
> refined. This example is just to give the reader a basic idea of
> things.
>
> [3] Should script/myapp_setup.pl exist in a PAR archive in order to
> prevent the problem of the script not running because of missing
> dependencies?
>
> [4] Should script/myapp_setup.pl always run through the installation
> scripts (Module::ScanDeps, perl Makefile.PL, make, make test, make
> install) every time the program runs, or should it just do it during
> its first run and at the user's request? Perhaps the script could be
> split into two parts: one of which runs through the installation
> scripts, and the other containing the server with the GUI forms where
> the user enters the rest of the setup information.
>
>
> On Wed, May 14, 2008 at 4:21 AM, Kieren Diment <diment[at]gmail.com> wrote:
>>
>> On 14 May 2008, at 18:43, Andreas Marienborg wrote:
>>>
>>> I would say that making sure the deps are correct would not be the job of
>>> CatalystX::Installer, but the developer of the app.
>>>
>>
>> Yes, but it's useful ^W essential to let the dev team know when they've
>> stuffed up.
>>
>>
>>> What I hope CatalystX::Installer will be, is something that I can use in
>>> my apps to make them easier to set up for people installing the app.
>>>
>>> This for me includes:
>>>
>>> - dependency handling
>>> any deps the app needs, that isn't available, or the wrong version should
>>> be installed / helped installed. For instance, a debian user might want
>>> suggestions for debian packages to install (quite large scope :p) For me it
>>> should not infer deps automaticly at this time, that the developer should do
>>> before releasing his app.
>>>
>>
>> yep, local:lib or par i'm not sure which. Someone else can answer this one.
>>
>>
>>> - app configuration
>>> Databases, paths, etc. This needs to be very customizable/pluggable. For
>>> instance in easycms2, I have a config setting for what resizes to make of
>>> pictures. It would be classy if I could easily map this to some webform
>>> using CatalystX::Installer :p
>>>
>>
>> +1
>>
>>> - schema deployment / upgrades
>>> Deploy or upgrade the given database-configuration. This sort of infers
>>> that the CatalystX::Installer also can be used for upgrades :p
>>>
>>
>>
>> hmm, scope creep
>>
>>> - example configurations
>>> For apache, lighty, nginx, perlbal(?), http-server, fastcgi etc.
>>> Perhaps it could even go as far as trying to put config under the propper
>>> /etc/apache/conf-enabled or whatever (this becomes distro-specific, and
>>> probably needs to be pluggable)
>>>
>>
>> yep, sounds fine for a prototype
>>
>>> - Running tests.
>>> This I think is a cool idea, to optionally run tests against the finished
>>> setup. The author should perhaps specify which tests to run
>>>
>>>
>>
>> and the name of the server to run them against.
>>
>>> - andreas
>>>
>>
>> Thanks for the input.
>>
>> _______________________________________________
>> List: Catalyst[at]lists.scsys.co.uk
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
>> Dev site: http://dev.catalyst.perl.org/
>>
>
_______________________________________________
List: Catalyst[at]lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst[at]lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
|
