[Catalyst-dev] Google Summer of Code: Rough Draft Proposal for Generic GUI for Catalyst apps

[Kieren Diment]

Hi Paul, thanks for this.  Please followup to  catalyst- 
dev at lists.scsys.co.uk (I have posted this there already)  rather than  
the psoc list - you'll have to susbscribe.

Also my comments are my comments.  Marcus may well tell you that i'm  
insane in places and some of my comments are useless ;)

Also come and idle on #catalyst and #catalyst-dev on irc.perl.org

Remaining comments inline.

>
> *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 application 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 that provides a generic  
> GUI for
> the deployment of Catalyst applications.
>
> *Project Details*
>
> For the generic GUI for Catalyst applications, 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. A quote from Marcus helps to  
> summarize:
>


Eric was right, you'll neeed to pare this quote down and move to your  
own words a bit.


> "When you install applications on a web server, most php apps, and  
> some
> perl apps like moveabletype present a wizard for setup, that asks
> common questions like what is the name of your app, where does your
> database live (and sets up the database and such for you), various
> system settings like that. Most of the screens are fairly generic,  
> and ... [snipped]"
>
> 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 sh=
> e
> installs.

Well you're not going to hit 100% of the config with this approach,  
but providing a design that makes for an easily extended config  
wizard approach so that people have config scaffolding would be great.


>
> There are of course some uncertainties for this application. One of  
> the mai=
> n
> foreseeable problems for this application will be making the GUI  
> generic
> enough where works for all programs, but not so generic that  
> installing
> party needs to use other tools besides this program 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 on=
> e
> 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, th=
> e
> 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 =96 Project Begins
>
>

my thoughts here are

Do we want to upload a dist-file  (i.e. from make dist) into the  
server root, and a myapp_install.cgi to cgi-bin.  This would then:

unarchive the myapp to somewhere sensible (like /tmp to start with)  
and check the Makefile.PL to make sure that all the dependencies are  
there (and prompt the user for action if not).  Then try running the  
application to see if it runs ok, if not point the user to the  
problems and ask them to fix them.

After this, you have the fun of asking the user for various canned  
fastcgi or mod_perl recipes (let's forget the alternatives).  I'd aim  
for fastcgi deployment on apache, lighttpd and nginx here.

There's your alpha 1



>    -
>
>    Monday, June 9 =96 Alpha 1 released
>
>    -

Support different dsns and think about supporting apps deployed  
behind a front end proxy.

>
>    Monday, June 16 -- Alpha 2 released
>
>    -

Start prototyping user-extension templates

>
>    Monday, June 23 =96 Alpha 3 released
>
>    -

Break the user-extension templates

>
>    Monday, July 7 =96 Beta 1 released in time for Midterms
>
>    -


maybe we want to half the number of alphas and betas - I'm running  
out of comments ;)  anyhow you get the idea.  Given that you're  
planning a process it's difficult to anticipate what's going to come  
up, such a detailed alpha and beta schedule is maybe not advisable -  
possibly functional milestones are a better idea (i.e. the kinds of  
suggestions that I've made above).


Finally a name:  I suggest CatalystX::Installer.

Like I say, my comments may be wrong.  Let marcus confirm.


>


Kieren