From rkitover at io.com  Tue Apr  1 16:58:44 2008
From: rkitover at io.com (Rafael Kitover)
Date: Tue Apr  1 16:56:25 2008
Subject: [Catalyst-dev] RFC: Catalyst::Plugin::SmartURI
Message-ID: <47F25BB4.8090504@io.com>

I've uploaded a dev release to CPAN as:
Catalyst-Plugin-SmartURI-0.01_01.tar.gz
http://pause.perl.org/incoming/Catalyst-Plugin-SmartURI-0.01_01.tar.gz
It's in svn here:
http://dev.catalystframework.org/svnweb/Catalyst/browse/Catalyst-Plugin-SmartURI/1.000/trunk/

mst came up with the design on #catalyst, implementation is close to 
what he suggested.

docs are probably not that great yet...

NAME
       Catalyst::Plugin::SmartURI - Configurable URIs for Catalyst

VERSION
       Version 0.01_01

SYNOPSIS
           smarturi:
               disposition: hostless # application-wide

           $c->uri_disposition('absolute'); # per request

           <a href="[% c.uri_for('/foo').relative %]" ...

       Configure whether $c->uri_for and $c->req->uri_with return absolute,
       hostless or relative URIs and/or configure which URI class to use, on
       an application or request basis.

       This is useful in situations where you?re for example, 
redirecting to a
       lighttpd from a firewall rule, instead of a real proxy, and you want
       your links and redirects to still work correctly.

DESCRIPTION
       This plugin allows you to configure, on a application and per-request
       basis, what URI class $c->uri_for and $c->req->uri_with use, as 
well as
       whether the URIs they produce are absolute, hostless or relative.

       To use your own URI class, just subclass Catalyst::SmartURI and set
       uri_class, or write a class that follows the same interface.

       This plugin installs a custom $c->request_class, however it does 
so in
       a way that won?t break if you?ve already set your own request_class.

       There will be a slight performance penalty for your first few 
requests,
       due to the way Catalyst::SmartURI works, but after that you shouldn?t
       notice it. The penalty is considerably smaller in perl 5.10+.

CONFIGURATION
       In myapp.yml:

           smarturi:
               dispostion: absolute
               uri_class: 'Catalyst::SmartURI'

       disposition
           One of ?absolute?, ?hostless? or ?relative?. Defaults to
           ?absolute?.

       uri_class
           The class to use for URIs, defaults to Catalyst::SmartURI.

PER REQUEST
           package MyAPP::Controller::RSSFeed;

           ...

           sub begin : Private {
               my ($self, $c) = @_;

               $c->uri_class('Your::URI::Class'); # if you need
               $c->uri_disposition('absolute'); # rest of app configured 
differently
           }

       $c->uri_disposition(?absolute?|?hostless?|?relative?)
           Set URI disposition to use for the duration of the request.

       $c->uri_class($class)
           Set the URI class to use for $c->uri_for and 
$c->req->uri_with for
           the duration of the request.

EXTENDING
       $c->prepare_uri actually creates the URI, you can overload that to do
       as you please in your own plugins.

From daniel at ruoso.com  Thu Apr  3 14:23:16 2008
From: daniel at ruoso.com (Daniel Ruoso)
Date: Thu Apr  3 14:23:22 2008
Subject: [Catalyst-dev] RFC - Catalyst::Engine::XMPP2
Message-ID: <1207228996.5957.11.camel@pitombeira>

Hi,

After Catalyst::Controller::SOAP having support for WSDL, my next step
is working to support XMPP as an engine, so I can deploy Web Services
using the XMPP protocol, that allows me other choreographies than simple
request-response. I can have things like;


 A ---req----> B ---broadcast -----> C
 ^                      |----------> D
 |                      \----------> E ---------\
 \-----------------req-------------- F <--req---/  


Where A might be an agent that interacts with the user interface that
needs to be notified when an operation deep in the choreografy is
realized.

So, this is the proposed implementation (actually the documentation for
the proposed implementation) of a XMPP engine. The name of the module is
XMPP2 because it uses the Net::XMPP2 module.

___


NAME
Catalyst::Engine::XMPP2 - Net::XMPP2::Connection Catalyst Engine


________________________________________________________________________
SYNOPSIS
MyApp->config->{xmpp} =
   {
    username => "abc",
    domain => "jabber.org",
    password => "foo",
    override_host => "myserver",
    override_port => 5722
   };
  MyApp->run();


________________________________________________________________________
DESCRIPTION
This engine enables you to deploy a Catalyst application that can be
accessed using the XMPP protocol. This is done by a mapping of each XMPP
stanza to a HTTP Request, using the Catalyst::Engine::Embeddable as a
base.


________________________________________________________________________
Semantics mapping
One important thing to realise is that the XMPP semantics are
considerably different than the HTTP semantics, that way, a set of
mappings must be done.


Request-Response
        
        Usually, an HTTP application implements only Request-Response
        semantics for every action. That is not always true for the XMPP
        protocol. In fact, the only stanza that implements this
        semantics is the <iq/> stanza.
        
        That way, when receiving <message/> or <presence/> stanzas, the
        response will be ignored on success. If the response is a
        failure (400 or 500), an error response will be sent. If wanting
        to send an explicit message, that should be done explicitly.
        
        When receiving <iq/> stanzas, the response will be sent back as
        the action processing returns, independent of the response
        status.
        
        In any way, the attributes of the stanza root element will be
        translated as HTTP Headers with the ``XMPP_Stanza_'' prefix.
        
SCRIPT_NAME
        
        This is the most relevant aspect of this mapping. As XMPP
        doesn't have a URI definition for each stanza, that means that
        there's no proper way of dispatching a message to a given
        controller action in Catalyst.
        
        What this mapping does is, at the beggining, creating several
        connections to the server, providing different resource
        identifiers based on the Path actions registered in the
        application.
        
        This have two important side-effects to realize:
        
        A Catalyst XMPP application can only use 'Path' actions, because
        that is the only DispatchType that have a static mapping of the
        available actions. Other DispatchTypes, like Chained or Index,
        depends on the current request to find out which action to
        dispatch. This doesn't forbid the use of the other DispatchTypes
        for internal forward and dispatch, but the only really public
        actions will be the ones seen by the 'Path' DispatchType.
        
        You have to keep in mind that the resources will be
        pre-advertised, and that for each public path action, you will
        have a public jabber id, and, at least by now, a separated
        connection to the server, so it's probably a good idea to do a
        carefull planning of which actions to make public.
        
Content-Type
        
        XMPP has no support for MIME types. Every message is, by
        definition, a XML document. So every request will have the
        ``application/xml'' MIME type. If the response content-type is
        also ``application/xml'', it will be written as raw into the
        XMPP stream. This will allow SOAP responses, for instance, to be
        sent as in XEP-0072.
        
        On the other hand, if the content type is of some other type, it
        will be sent as encoded string inside a <body> tag, as described
        by XMPP RFC3921, this way, interaction with regular IM clients
        should be natural.
        
Scalability
        
        At this point, this engine is single-threaded, which means that
        it will block in each operation, and, therefore it cannot handle
        more than one request at a time. At the time of this writing,
        two options are available to solve this problem:
        
        The first would be to turn this engine into a pre-fork server
        that would keep pipes to every child and dispatch the requests
        to them, while keeping a single control thread for the XMPP
        connections.
        
        The other option would be to implement a balancer server that
        would accept several connections for the same JID and connect
        only once for each JID, dispatching a message sent to some JID
        among each of the candidate connections.
        
        The second option is probably a better idea, as the handling of
        that number of connections could be implemented in C, for
        instance, and using low-level OS operations, like libevent for
        linux, making it easier to scale in several machines.
        


________________________________________________________________________
USAGE
The 'xmpp' configuration key expects a hashref that will be sent to
Net::XMPP2::Connection->new dereferenced. It's important to notice,
however, that setting ``jid'' or ``resource'' in this hash has no effect
as this values will be set according to the Action-Resource mapping.


---


daniel




From ton.voon at altinity.com  Thu Apr  3 22:49:19 2008
From: ton.voon at altinity.com (Ton Voon)
Date: Thu Apr  3 22:49:38 2008
Subject: [Catalyst-dev] HTTP engine closing socket on header failure
Message-ID: <0F1FDB3E-D8D4-4CC7-9B60-24F0C1039760@altinity.com>

Hi!

We hit a problem with the HTTP development engine where a connection  
would come in without any headers and the remote socket wasn't being  
closed correctly.

This patch to Catalyst::Engine::HTTP closes the Remote connection and  
also prints debug statements around the sysread.

Ton

http://www.altinity.com
UK: +44 (0)870 787 9243
US: +1 866 879 9184
Fax: +44 (0)845 280 1725
Skype: tonvoon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Catalyst-Engine-HTTP_retry_on_ewouldblock.patch
Type: application/octet-stream
Size: 812 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/catalyst-dev/attachments/20080403/2ec6ca09/Catalyst-Engine-HTTP_retry_on_ewouldblock.obj
From jon at jrock.us  Fri Apr  4 07:55:42 2008
From: jon at jrock.us (Jonathan Rockway)
Date: Fri Apr  4 07:55:44 2008
Subject: [Catalyst-dev] HTTP engine closing socket on header failure
In-Reply-To: <0F1FDB3E-D8D4-4CC7-9B60-24F0C1039760@altinity.com> (Ton Voon's
	message of "Thu, 3 Apr 2008 22:49:19 +0100")
References: <0F1FDB3E-D8D4-4CC7-9B60-24F0C1039760@altinity.com>
Message-ID: <878wzucdn5.fsf@bar.jrock.us>

* On Thu, Apr 03 2008, Ton Voon wrote:
> Hi!
>
> We hit a problem with the HTTP development engine where a connection
> would come in without any headers and the remote socket wasn't being
> closed correctly.
>
> This patch to Catalyst::Engine::HTTP closes the Remote connection and
> also prints debug statements around the sysread.

Can you include a test for this also?

-- 
print just => another => perl => hacker => if $,=$"

From andy at hybridized.org  Fri Apr  4 17:08:13 2008
From: andy at hybridized.org (Andy Grundman)
Date: Fri Apr  4 17:08:23 2008
Subject: [Catalyst-dev] HTTP engine closing socket on header failure
In-Reply-To: <0F1FDB3E-D8D4-4CC7-9B60-24F0C1039760@altinity.com>
References: <0F1FDB3E-D8D4-4CC7-9B60-24F0C1039760@altinity.com>
Message-ID: <EEAFD065-D437-477A-9BEC-476218592912@hybridized.org>


On Apr 3, 2008, at 5:49 PM, Ton Voon wrote:
> Hi!
>
> We hit a problem with the HTTP development engine where a connection  
> would come in without any headers and the remote socket wasn't being  
> closed correctly.
>
> This patch to Catalyst::Engine::HTTP closes the Remote connection  
> and also prints debug statements around the sysread.

Thanks.  You're right that STDIN is set to non-blocking before  
_read_headers is called the second time, so it needs to support non- 
blocking mode.

Your patch looks sane, I've committed a slightly modified version.  A  
test case would be nice but I realize it's a bit hard in this case.  I  
tested manually and saw the connection bug with the old code, and the  
patch definitely fixes it.

-Andy


From ton.voon at altinity.com  Fri Apr  4 20:22:02 2008
From: ton.voon at altinity.com (Ton Voon)
Date: Fri Apr  4 20:22:16 2008
Subject: [Catalyst-dev] HTTP engine closing socket on header failure
In-Reply-To: <EEAFD065-D437-477A-9BEC-476218592912@hybridized.org>
References: <0F1FDB3E-D8D4-4CC7-9B60-24F0C1039760@altinity.com>
	<EEAFD065-D437-477A-9BEC-476218592912@hybridized.org>
Message-ID: <ED722CE4-9704-40DF-A7A9-10C707EA94D0@altinity.com>


On 4 Apr 2008, at 17:08, Andy Grundman wrote:
>
> On Apr 3, 2008, at 5:49 PM, Ton Voon wrote:
>> Hi!
>>
>> We hit a problem with the HTTP development engine where a  
>> connection would come in without any headers and the remote socket  
>> wasn't being closed correctly.
>>
>> This patch to Catalyst::Engine::HTTP closes the Remote connection  
>> and also prints debug statements around the sysread.
>
> Thanks.  You're right that STDIN is set to non-blocking before  
> _read_headers is called the second time, so it needs to support non- 
> blocking mode.
>
> Your patch looks sane, I've committed a slightly modified version.   
> A test case would be nice but I realize it's a bit hard in this  
> case.  I tested manually and saw the connection bug with the old  
> code, and the patch definitely fixes it.


Great - I'm glad you found it useful.

Actually, we did a bit more digging and found another limitation. The  
symptoms we were seeing was that the dev server was hanging on a  
read(), which is at the sysread() call in _read_headers. We don't  
understand why this happens, but since the _read_headers is done by  
the main myapp_server.pl process before a fork, this means that all  
subsequent connections hang until the sysread() times out (or the  
connection is closed - not sure which).

We've amended the code in C::E::HTTP within the accept() loop so that  
it forks immediately, instead of trying to read the headers first.  
This means the connection that was causing the problem (which is  
pretty random, about 5 times a day) hangs, but all other requests work  
fine thus isolating the issue.

The downside to this is that the RESTART method is not available  
anymore. Would you be interested in this patch?

Ton

http://www.altinity.com
UK: +44 (0)870 787 9243
US: +1 866 879 9184
Fax: +44 (0)845 280 1725
Skype: tonvoon


From andy at hybridized.org  Fri Apr  4 20:35:19 2008
From: andy at hybridized.org (Andy Grundman)
Date: Fri Apr  4 20:35:29 2008
Subject: [Catalyst-dev] HTTP engine closing socket on header failure
In-Reply-To: <ED722CE4-9704-40DF-A7A9-10C707EA94D0@altinity.com>
References: <0F1FDB3E-D8D4-4CC7-9B60-24F0C1039760@altinity.com>
	<EEAFD065-D437-477A-9BEC-476218592912@hybridized.org>
	<ED722CE4-9704-40DF-A7A9-10C707EA94D0@altinity.com>
Message-ID: <29B4D219-4ED6-4825-9402-542B728F152A@hybridized.org>


On Apr 4, 2008, at 3:22 PM, Ton Voon wrote:
>
> On 4 Apr 2008, at 17:08, Andy Grundman wrote:
>>
>> On Apr 3, 2008, at 5:49 PM, Ton Voon wrote:
>>> Hi!
>>>
>>> We hit a problem with the HTTP development engine where a  
>>> connection would come in without any headers and the remote socket  
>>> wasn't being closed correctly.
>>>
>>> This patch to Catalyst::Engine::HTTP closes the Remote connection  
>>> and also prints debug statements around the sysread.
>>
>> Thanks.  You're right that STDIN is set to non-blocking before  
>> _read_headers is called the second time, so it needs to support non- 
>> blocking mode.
>>
>> Your patch looks sane, I've committed a slightly modified version.   
>> A test case would be nice but I realize it's a bit hard in this  
>> case.  I tested manually and saw the connection bug with the old  
>> code, and the patch definitely fixes it.
>
>
> Great - I'm glad you found it useful.
>
> Actually, we did a bit more digging and found another limitation.  
> The symptoms we were seeing was that the dev server was hanging on a  
> read(), which is at the sysread() call in _read_headers. We don't  
> understand why this happens, but since the _read_headers is done by  
> the main myapp_server.pl process before a fork, this means that all  
> subsequent connections hang until the sysread() times out (or the  
> connection is closed - not sure which).
>
> We've amended the code in C::E::HTTP within the accept() loop so  
> that it forks immediately, instead of trying to read the headers  
> first. This means the connection that was causing the problem (which  
> is pretty random, about 5 times a day) hangs, but all other requests  
> work fine thus isolating the issue.
>
> The downside to this is that the RESTART method is not available  
> anymore. Would you be interested in this patch?
>
> Ton

Hmm, I don't want to break RESTART though.

You may be interested in a new engine I'm about to release hopefully  
later today that implements pre-forking and scales a lot better than  
the built-in HTTP engine.

From ton.voon at altinity.com  Fri Apr  4 21:04:27 2008
From: ton.voon at altinity.com (Ton Voon)
Date: Fri Apr  4 21:04:39 2008
Subject: [Catalyst-dev] HTTP engine closing socket on header failure
In-Reply-To: <29B4D219-4ED6-4825-9402-542B728F152A@hybridized.org>
References: <0F1FDB3E-D8D4-4CC7-9B60-24F0C1039760@altinity.com>
	<EEAFD065-D437-477A-9BEC-476218592912@hybridized.org>
	<ED722CE4-9704-40DF-A7A9-10C707EA94D0@altinity.com>
	<29B4D219-4ED6-4825-9402-542B728F152A@hybridized.org>
Message-ID: <D7C95D48-5C8D-4DD3-A41D-AD88848A2F11@altinity.com>


On 4 Apr 2008, at 20:35, Andy Grundman wrote:
> Hmm, I don't want to break RESTART though.

Actually, I just thought maybe you could use the $options->{restart}  
flag to decide whether to fork immediately or not. Would you go for  
that?

> You may be interested in a new engine I'm about to release hopefully  
> later today that implements pre-forking and scales a lot better than  
> the built-in HTTP engine.

That sounds very interesting. Would be happy to help test and develop.

Ton


From andy at hybridized.org  Fri Apr  4 21:12:05 2008
From: andy at hybridized.org (Andy Grundman)
Date: Fri Apr  4 21:12:14 2008
Subject: [Catalyst-dev] HTTP engine closing socket on header failure
In-Reply-To: <D7C95D48-5C8D-4DD3-A41D-AD88848A2F11@altinity.com>
References: <0F1FDB3E-D8D4-4CC7-9B60-24F0C1039760@altinity.com>
	<EEAFD065-D437-477A-9BEC-476218592912@hybridized.org>
	<ED722CE4-9704-40DF-A7A9-10C707EA94D0@altinity.com>
	<29B4D219-4ED6-4825-9402-542B728F152A@hybridized.org>
	<D7C95D48-5C8D-4DD3-A41D-AD88848A2F11@altinity.com>
Message-ID: <608A97D3-F9DB-4EE7-B8E7-2850938B02A5@hybridized.org>


On Apr 4, 2008, at 4:04 PM, Ton Voon wrote:
>
> On 4 Apr 2008, at 20:35, Andy Grundman wrote:
>> Hmm, I don't want to break RESTART though.
>
> Actually, I just thought maybe you could use the $options->{restart}  
> flag to decide whether to fork immediately or not. Would you go for  
> that?

Sure, that sounds good.

From diment at gmail.com  Sun Apr  6 12:23:37 2008
From: diment at gmail.com (Kieren Diment)
Date: Sun Apr  6 12:23:46 2008
Subject: [Catalyst-dev] Google Summer of Code: Rough Draft Proposal for
	Generic GUI for Catalyst apps
In-Reply-To: <a31f34090804052236w3425b9c1xa5dc061479dbfc5f@mail.gmail.com>
References: <a31f34090804052236w3425b9c1xa5dc061479dbfc5f@mail.gmail.com>
Message-ID: <C301FB56-CB44-4729-87EC-44960B5F2CEE@gmail.com>

Hi Paul, thanks for this.  Please followup to  catalyst- 
dev@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

From dbix-class at trout.me.uk  Sun Apr  6 18:25:33 2008
From: dbix-class at trout.me.uk (Matt S Trout)
Date: Sun Apr  6 18:25:34 2008
Subject: Fw: [Catalyst-dev] PATCH: for Catalyst-Utils home finding bug
Message-ID: <20080406172533.GJ11450@agaton.scsys.co.uk>

Did anybody review and apply this?

I can't really do the review since I helped diagnose it.

----- Forwarded message from John Goulah <jgoulah@gmail.com> -----

Return-Path: catalyst-dev-bounces@lists.scsys.co.uk
Delivered-To: matt@trout.me.uk
Received: (qmail 28115 invoked by alias); 20 Feb 2008 16:47:45 -0000
Delivered-To: dbix-class@trout.me.uk
Received: (qmail 28113 invoked from network); 20 Feb 2008 16:47:45 -0000
Received: from unknown (HELO jules.scsys.co.uk) (217.168.146.69)
  by 0 with SMTP; 20 Feb 2008 16:47:45 -0000
Received: from localhost ([127.0.0.1] helo=jules.scsys.co.uk)
	by jules.scsys.co.uk with esmtp (Exim 4.60)
	(envelope-from <catalyst-dev-bounces@lists.scsys.co.uk>)
	id 1JRscr-0000lI-To; Wed, 20 Feb 2008 17:20:57 +0000
Received: from wr-out-0506.google.com ([64.233.184.236])
	by jules.scsys.co.uk with esmtp (Exim 4.60)
	(envelope-from <jgoulah@gmail.com>) id 1JRscp-0000lD-Ek
	for catalyst-dev@lists.scsys.co.uk; Wed, 20 Feb 2008 17:20:55 +0000
Received: by wr-out-0506.google.com with SMTP id c47so2770450wra.20
	for <catalyst-dev@lists.scsys.co.uk>;
	Wed, 20 Feb 2008 09:20:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type;
	bh=qLjH37LLy/TZloDbeNvP4FiFnvQ11W6pARgPGF7Oc1s=;
	b=f55XoSofbufq1sEpRprGlFOFv+RcrLNCCdW+LloUhn4LWo2p6qNbH9VTA7Hb/edsDQJo6hU/g2v66KVMCK6g0syaIKC3/SMmsgfyPcjLU4vXe2atifB9F/nM+tlrNzYJRnMf6XLpTAEXookpwGRo9X7dFMi77ihWgqxLyAzr9mU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:mime-version:content-type;
	b=e0JMfgzpXuZFkZTJ0nvSwwvUuLsP0CWQvTpWQLJK9FtnzaiSsOiwkztJTKfCuBHMMihzF93zHr4WTPyf/lOt2pueU6ucw/xeGmKgYueKDfSo/y9yMrxCFkrgPto6dwt/o1A7cwBNW3EX4m1vgolwsGAVjv/zKJ7FMdNMqYqzHI0=
Received: by 10.141.171.6 with SMTP id y6mr5905864rvo.84.1203528052402;
	Wed, 20 Feb 2008 09:20:52 -0800 (PST)
Received: by 10.141.202.19 with HTTP; Wed, 20 Feb 2008 09:20:52 -0800 (PST)
Message-ID: <183c1cc10802200920t1febf65dh5d5850ddf57663b1@mail.gmail.com>
Date: Wed, 20 Feb 2008 12:20:52 -0500
From: John Goulah <jgoulah@gmail.com>
To: catalyst-dev@lists.scsys.co.uk
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_15834_3483285.1203528052408"
Subject: [Catalyst-dev] PATCH: for Catalyst-Utils home finding bug
X-BeenThere: catalyst-dev@lists.scsys.co.uk
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Development of the elegant MVC web framework <catalyst-dev@lists.scsys.co.uk>
List-Id: Development of the elegant MVC web framework
	<catalyst-dev.lists.scsys.co.uk>
List-Unsubscribe: <http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev>,
	<mailto:catalyst-dev-request@lists.scsys.co.uk?subject=unsubscribe>
List-Archive: <http://lists.scsys.co.uk/pipermail/catalyst-dev>
List-Post: <mailto:catalyst-dev@lists.scsys.co.uk>
List-Help: <mailto:catalyst-dev-request@lists.scsys.co.uk?subject=help>
List-Subscribe: <http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev>,
	<mailto:catalyst-dev-request@lists.scsys.co.uk?subject=subscribe>
Errors-To: catalyst-dev-bounces@lists.scsys.co.uk

Here is a patch to fix the Catalyst home finding bug for scripts that run in
directories more than one level deep.  Feel free to rename the test.  If
there is some better way to test, let me know, but it fails under the
current code and passes with the attached patch.

Also these dirs must be added, along with the empty Makefile.PL

A      Catalyst-Runtime/5.70/trunk/t/something
A      Catalyst-Runtime/5.70/trunk/t/something/script
A      Catalyst-Runtime/5.70/trunk/t/something/script/foo
A      Catalyst-Runtime/5.70/trunk/t/something/script/foo/bar
A      Catalyst-Runtime/5.70/trunk/t/something/Makefile.PL


Thanks!
John


_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


----- End forwarded message -----

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/

From marcus at nordaaker.com  Sun Apr  6 20:43:15 2008
From: marcus at nordaaker.com (Marcus Ramberg)
Date: Sun Apr  6 20:43:21 2008
Subject: [Catalyst-dev] PATCH: for Catalyst-Utils home finding bug
In-Reply-To: <20080406172533.GJ11450@agaton.scsys.co.uk>
References: <20080406172533.GJ11450@agaton.scsys.co.uk>
Message-ID: <282A18AD-5B32-4A2B-BF3D-C078532EE193@nordaaker.com>

Looks good
Merge back committed as revision 7576.

On 6. april. 2008, at 19.25, Matt S Trout wrote:
> Did anybody review and apply this?
>
> I can't really do the review since I helped diagnose it.
>
> ----- Forwarded message from John Goulah <jgoulah@gmail.com> -----
>
> Return-Path: catalyst-dev-bounces@lists.scsys.co.uk
> Delivered-To: matt@trout.me.uk
> Received: (qmail 28115 invoked by alias); 20 Feb 2008 16:47:45 -0000
> Delivered-To: dbix-class@trout.me.uk
> Received: (qmail 28113 invoked from network); 20 Feb 2008 16:47:45  
> -0000
> Received: from unknown (HELO jules.scsys.co.uk) (217.168.146.69)
>  by 0 with SMTP; 20 Feb 2008 16:47:45 -0000
> Received: from localhost ([127.0.0.1] helo=jules.scsys.co.uk)
> 	by jules.scsys.co.uk with esmtp (Exim 4.60)
> 	(envelope-from <catalyst-dev-bounces@lists.scsys.co.uk>)
> 	id 1JRscr-0000lI-To; Wed, 20 Feb 2008 17:20:57 +0000
> Received: from wr-out-0506.google.com ([64.233.184.236])
> 	by jules.scsys.co.uk with esmtp (Exim 4.60)
> 	(envelope-from <jgoulah@gmail.com>) id 1JRscp-0000lD-Ek
> 	for catalyst-dev@lists.scsys.co.uk; Wed, 20 Feb 2008 17:20:55 +0000
> Received: by wr-out-0506.google.com with SMTP id c47so2770450wra.20
> 	for <catalyst-dev@lists.scsys.co.uk>;
> 	Wed, 20 Feb 2008 09:20:53 -0800 (PST)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com;  
> s=gamma;
> 	h=domainkey-signature:received:received:message- 
> id:date:from:to:subject:mime-version:content-type;
> 	bh=qLjH37LLy/TZloDbeNvP4FiFnvQ11W6pARgPGF7Oc1s=;
> 	b=f55XoSofbufq1sEpRprGlFOFv+RcrLNCCdW+LloUhn4LWo2p6qNbH9VTA7Hb/ 
> edsDQJo6hU/g2v66KVMCK6g0syaIKC3/SMmsgfyPcjLU4vXe2atifB9F/nM 
> +tlrNzYJRnMf6XLpTAEXookpwGRo9X7dFMi77ihWgqxLyAzr9mU=
> DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
> 	h=message-id:date:from:to:subject:mime-version:content-type;
> 	 
> b 
> = 
> e0JMfgzpXuZFkZTJ0nvSwwvUuLsP0CWQvTpWQLJK9FtnzaiSsOiwkztJTKfCuBHMMihzF93zHr4WTPyf 
> /lOt2pueU6ucw/xeGmKgYueKDfSo/y9yMrxCFkrgPto6dwt/ 
> o1A7cwBNW3EX4m1vgolwsGAVjv/zKJ7FMdNMqYqzHI0=
> Received: by 10.141.171.6 with SMTP id y6mr5905864rvo. 
> 84.1203528052402;
> 	Wed, 20 Feb 2008 09:20:52 -0800 (PST)
> Received: by 10.141.202.19 with HTTP; Wed, 20 Feb 2008 09:20:52  
> -0800 (PST)
> Message-ID: <183c1cc10802200920t1febf65dh5d5850ddf57663b1@mail.gmail.com 
> >
> Date: Wed, 20 Feb 2008 12:20:52 -0500
> From: John Goulah <jgoulah@gmail.com>
> To: catalyst-dev@lists.scsys.co.uk
> MIME-Version: 1.0
> Content-Type: multipart/mixed;
> 	boundary="----=_Part_15834_3483285.1203528052408"
> Subject: [Catalyst-dev] PATCH: for Catalyst-Utils home finding bug
> X-BeenThere: catalyst-dev@lists.scsys.co.uk
> X-Mailman-Version: 2.1.5
> Precedence: list
> Reply-To: Development of the elegant MVC web framework <catalyst-dev@lists.scsys.co.uk 
> >
> List-Id: Development of the elegant MVC web framework
> 	<catalyst-dev.lists.scsys.co.uk>
> List-Unsubscribe: <http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev 
> >,
> 	<mailto:catalyst-dev-request@lists.scsys.co.uk?subject=unsubscribe>
> List-Archive: <http://lists.scsys.co.uk/pipermail/catalyst-dev>
> List-Post: <mailto:catalyst-dev@lists.scsys.co.uk>
> List-Help: <mailto:catalyst-dev-request@lists.scsys.co.uk? 
> subject=help>
> List-Subscribe: <http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev 
> >,
> 	<mailto:catalyst-dev-request@lists.scsys.co.uk?subject=subscribe>
> Errors-To: catalyst-dev-bounces@lists.scsys.co.uk
>
> Here is a patch to fix the Catalyst home finding bug for scripts  
> that run in
> directories more than one level deep.  Feel free to rename the  
> test.  If
> there is some better way to test, let me know, but it fails under the
> current code and passes with the attached patch.
>
> Also these dirs must be added, along with the empty Makefile.PL
>
> A      Catalyst-Runtime/5.70/trunk/t/something
> A      Catalyst-Runtime/5.70/trunk/t/something/script
> A      Catalyst-Runtime/5.70/trunk/t/something/script/foo
> A      Catalyst-Runtime/5.70/trunk/t/something/script/foo/bar
> A      Catalyst-Runtime/5.70/trunk/t/something/Makefile.PL
>
>
> Thanks!
> John
>
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev@lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>
>
> ----- End forwarded message -----
>
> -- 
>      Matt S Trout       Need help with your Catalyst or DBIx::Class  
> project?
>   Technical Director                    http://www.shadowcat.co.uk/catalyst/
> Shadowcat Systems Ltd.  Want a managed development or deployment  
> platform?
> http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev@lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev


From dbix-class at trout.me.uk  Sun Apr  6 20:49:30 2008
From: dbix-class at trout.me.uk (Matt S Trout)
Date: Sun Apr  6 20:49:31 2008
Subject: [Catalyst-dev] Moose port progress report
In-Reply-To: <B3F37007-C9B5-4287-B1DB-B45250F32960@altrion.org>
References: <725117.94538.qm@web30408.mail.mud.yahoo.com>
	<alpine.DEB.0.9999.0803310938120.504@urth.org>
	<B3F37007-C9B5-4287-B1DB-B45250F32960@altrion.org>
Message-ID: <20080406194930.GK12180@agaton.scsys.co.uk>

On Mon, Mar 31, 2008 at 05:39:56PM +0100, Mike Whitaker wrote:
> 
> On 31 Mar 2008, at 15:39, Dave Rolsky wrote:
> 
> >On Mon, 31 Mar 2008, John Napiorkowski wrote:
> >
> >>This would make a plugin I'm working on for monitoring/restarting  
> >>the application a lot easier. I've had to do a lot of hacking just  
> >>to simulate role stuff, so I am in favor of it.  However I think  
> >>people who have a lot of existing plugins might feel nervious :)
> >
> >Personally, I'd like to see this work get be aggressive in its  
> >breakage of old idioms, but have it released under a new namespace,  
> >like Catalyst6.
> >
> >There's a lot of cruft in Catalyst worth excising, but at the same  
> >time, I don't want a simple "cpan install Catalyst" to break my  
> >apps horribly ;)
> 
> Could we perhaps have a combination of a) a deprecation cycle and b)  
> an 'if your app breaks, set <this> config option'?

That's what we've always done before.

My intent is to get 5.80 shipped as basically fully compatible, and have
the app/ctx switch clean things up, so

use Catalyst; # will do what it always have

but

use Catalyst::AppClass; # will make us isa Catalyst::Application only

I'd also rather get away from the import style entirely, tbh; I'd prefer
a ketword-style approach ala Moose instead.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/

From marcus at nordaaker.com  Sun Apr  6 22:38:05 2008
From: marcus at nordaaker.com (Marcus Ramberg)
Date: Sun Apr  6 22:38:11 2008
Subject: [Catalyst-dev] Moose port progress report
In-Reply-To: <20080406194930.GK12180@agaton.scsys.co.uk>
References: <725117.94538.qm@web30408.mail.mud.yahoo.com>
	<alpine.DEB.0.9999.0803310938120.504@urth.org>
	<B3F37007-C9B5-4287-B1DB-B45250F32960@altrion.org>
	<20080406194930.GK12180@agaton.scsys.co.uk>
Message-ID: <25F8B250-8D49-4CAC-A5DA-923E54C7935B@nordaaker.com>


On 6. april. 2008, at 21.49, Matt S Trout wrote:
>>
>> Could we perhaps have a combination of a) a deprecation cycle and b)
>> an 'if your app breaks, set <this> config option'?
>
> That's what we've always done before.
>
> My intent is to get 5.80 shipped as basically fully compatible, and  
> have
> the app/ctx switch clean things up, so
>
> use Catalyst; # will do what it always have
>
> but
>
> use Catalyst::AppClass; # will make us isa Catalyst::Application only
>
> I'd also rather get away from the import style entirely, tbh; I'd  
> prefer
> a ketword-style approach ala Moose instead.

I agree with the approach of releasing a fully compat moose 5.8  
version. I've just released a new version of Catalyst::Devel, (1.04)  
which generates MyApp.pm with "use parent qw/MyApp/" so that  
controller doesn't get inserted into MyApp's isa.

changing the load style seems like a good approach for brining in the  
new way of using things, while maintainin backwards compat, when we're  
beyond 5.8.

I plan to do a 5.7100 release of Catalyst-Runtime this week with some  
bug fixes and a few minor new features. What's the current estimated  
time for the 5.8 release?

Marcus
Catalyst Release Manager.

From fat.perl.hacker at gmail.com  Mon Apr  7 08:46:18 2008
From: fat.perl.hacker at gmail.com (Paul Cain)
Date: Mon Apr  7 08:46:22 2008
Subject: [Catalyst-dev] 2nd Draft Proposal for the Generic GUI for
	installing Catalyst Apps(CatalystX::Installer)
Message-ID: <a31f34090804070046l3947b807p7cd5433115029354@mail.gmail.com>

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@gmail.com*

*CatalystX::Installer =96 A generic GUI deployment for catalyst application=
s*





 *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=3DCatalystX::Installer::Forms::SelectionList->new=
();
$preferred_config_type->add({
    'YAML' =3D> "YAML",
    'INI' =3D> 'Windows INI File',
    'XML' =3D> '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 =96 Project Begins

   -

   Monday, June 9 =96 Alpha 1 released =96 APIs for the basic program are
   complete

   -

   Monday, June 30-- Alpha 2 released =96 User extension APIs are complete

   -

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

   -

   Monday, July 21 =96 Beta 2 released =96 mainly just bug fixes

   -

   Monday, August 4th =96 Release Candidate 1 released

   -

   August 11 =96 Release Candidate 2 released =96 This release may be skipp=
ed
   if no show-stopping bugs are found in RC1

   -

   August 18 =96 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst-dev/attachments/20080407/e=
fc27f81/attachment-0001.htm
From daniel at ruoso.com  Mon Apr  7 12:56:58 2008
From: daniel at ruoso.com (Daniel Ruoso)
Date: Mon Apr  7 12:57:04 2008
Subject: [Catalyst-dev] RFC - Catalyst::Engine::XMPP2
In-Reply-To: <1207228996.5957.11.camel@pitombeira>
References: <1207228996.5957.11.camel@pitombeira>
Message-ID: <1207569418.5303.9.camel@pitombeira>

UXVpLCAyMDA4LTA0LTAzIMOgcyAxNDoyMyArMDEwMCwgRGFuaWVsIFJ1b3NvIGVzY3JldmV1Ogo+
IFNvLCB0aGlzIGlzIHRoZSBwcm9wb3NlZCBpbXBsZW1lbnRhdGlvbiAoYWN0dWFsbHkgdGhlIGRv
Y3VtZW50YXRpb24gZm9yCj4gdGhlIHByb3Bvc2VkIGltcGxlbWVudGF0aW9uKSBvZiBhIFhNUFAg
ZW5naW5lLiBUaGUgbmFtZSBvZiB0aGUgbW9kdWxlIGlzCj4gWE1QUDIgYmVjYXVzZSBpdCB1c2Vz
IHRoZSBOZXQ6OlhNUFAyIG1vZHVsZS4KCkZvciB0aG9zZSBmb2xsb3dpbmcsIHRoZSBmaXJzdCB2
ZXJzaW9uIG9mIENhdGFseXN0OjpFbmdpbmU6OlhNUFAyIGlzCnJlYWR5LiBJdCB3YXMgbm90IHB1
Ymxpc2hlZCB5ZXQgYmVjYXVzZSBpdCBkZXBlbmRzIG9uIGEgdW5wdWJsaXNoZWQKYnVnZml4IGlu
IEhUVFA6OkJvZHkuCgpZb3UgY2FuIHRlc3QgaXQgYWxyZWFkeSBieSBkb2luZwoKZ2l0IGNsb25l
Cmh0dHA6Ly9wZW9wbGUuZGViaWFuLm9yZy9+cnVvc28vY2F0YWx5c3QvQ2F0YWx5c3QtRW5naW5l
LVhNUFAyLmdpdAoKQnV0IHRoZSB0ZXN0cyB3aWxsIGZhaWwsIHVubGVzcyB5b3UgYXBwbHkgdGhl
IGF0dGFjaGVkIHBhdGNoIGluCkhUVFA6OkJvZHksIG9yIHVubGVzcyB0aGUgcGF0Y2ggaXMgcHVi
bGlzaGVkIGJlZm9yZSB0aGF0IDspCgpkYW5pZWwKLS0tLS0tLS0tLS0tLS0gbmV4dCBwYXJ0IC0t
LS0tLS0tLS0tLS0tCkEgbm9uLXRleHQgYXR0YWNobWVudCB3YXMgc2NydWJiZWQuLi4KTmFtZTog
SFRUUC1Cb2R5LVhGb3Jtcy1Cb2R5LnBhdGNoClR5cGU6IHRleHQveC1wYXRjaApTaXplOiAyMDI5
IGJ5dGVzCkRlc2M6IG5vdCBhdmFpbGFibGUKVXJsIDogaHR0cDovL2xpc3RzLnNjc3lzLmNvLnVr
L3BpcGVybWFpbC9jYXRhbHlzdC1kZXYvYXR0YWNobWVudHMvMjAwODA0MDcvNzg5NDRkNjAvSFRU
UC1Cb2R5LVhGb3Jtcy1Cb2R5LmJpbgo=
From marcus at nordaaker.com  Mon Apr  7 17:46:54 2008
From: marcus at nordaaker.com (Marcus Ramberg)
Date: Mon Apr  7 17:47:05 2008
Subject: [Catalyst-dev] 2nd Draft Proposal for the Generic GUI for
	installing Catalyst Apps(CatalystX::Installer)
In-Reply-To: <a31f34090804070046l3947b807p7cd5433115029354@mail.gmail.com>
References: <a31f34090804070046l3947b807p7cd5433115029354@mail.gmail.com>
Message-ID: <522FE6E2-16C5-4D67-B256-D316365D193F@nordaaker.com>


On 7. april. 2008, at 09.46, Paul Cain wrote:
> 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.
>

Hi Paul.

Your proposal looks quite good. A few comments below

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

It might make sense to build the Forms stuff on top of HTML::FormFu.

>
> 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.
>

Of these two, I prefer the first approach, as it's more in line with  
how Catalyst does other things.

[ ... ]
>
>
>
>   *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.
>

If you want, I'd be happy to mentor this project.

Good luck with the process, and don't hestiate to contact me or any of  
the other catalyst developers on IRC again. Note that a lot of us are  
always connected (using screen or irc), so we get your messages even  
if we might be away from our computers, and are slow to respond)

Marcus
From fat.perl.hacker at gmail.com  Mon Apr  7 18:15:25 2008
From: fat.perl.hacker at gmail.com (Paul Cain)
Date: Mon Apr  7 18:15:34 2008
Subject: [Catalyst-dev] 2nd Draft Proposal for the Generic GUI for
	installing Catalyst Apps(CatalystX::Installer)
In-Reply-To: <522FE6E2-16C5-4D67-B256-D316365D193F@nordaaker.com>
References: <a31f34090804070046l3947b807p7cd5433115029354@mail.gmail.com>
	<522FE6E2-16C5-4D67-B256-D316365D193F@nordaaker.com>
Message-ID: <a31f34090804071015k6694bc35o2956879dc6a555bf@mail.gmail.com>

Hey Marcus,

Thanks for your input; I think it would be great if you were my mentor.

I like the first approach better too.

I'll make a few small tweaks to the proposal and then submit it to Google
with 6.5 hours to spare before the deadline.

On Mon, Apr 7, 2008 at 11:46 AM, Marcus Ramberg <marcus@nordaaker.com>
wrote:

>
> On 7. april. 2008, at 09.46, Paul Cain wrote:
>
> > 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.
> >
> >
> Hi Paul.
>
> Your proposal looks quite good. A few comments below
>
>
> > my
> > $preferred_config_type=3DCatalystX::Installer::Forms::SelectionList->ne=
w();
> > $preferred_config_type->add({
> >   'YAML' =3D> "YAML",
> >   'INI' =3D> 'Windows INI File',
> >   'XML' =3D> 'XML',
> > });
> >
> >
> It might make sense to build the Forms stuff on top of HTML::FormFu.
>
>
>
> > 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.
> >
> >
> Of these two, I prefer the first approach, as it's more in line with how
> Catalyst does other things.
>
> [ ... ]
>
> >
> >
> >
> >  *Project Schedule*
> >
> >  -
> >
> >  May 26 =96 Project Begins
> >
> >  -
> >
> >  Monday, June 9 =96 Alpha 1 released =96 APIs for the basic program are
> >  complete
> >
> >  -
> >
> >  Monday, June 30-- Alpha 2 released =96 User extension APIs are complete
> >
> >  -
> >
> >  Monday, July 7 =96 Beta 1 released =96 All features exist now in the
> >  program; program will be distributed to any willing victims for testing
> >
> >  -
> >
> >  Monday, July 21 =96 Beta 2 released =96 mainly just bug fixes
> >
> >  -
> >
> >  Monday, August 4th =96 Release Candidate 1 released
> >
> >  -
> >
> >  August 11 =96 Release Candidate 2 released =96 This release may be ski=
pped
> >  if no show-stopping bugs are found in RC1
> >
> >  -
> >
> >  August 18 =96 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.
> >
> >
> If you want, I'd be happy to mentor this project.
>
> Good luck with the process, and don't hestiate to contact me or any of the
> other catalyst developers on IRC again. Note that a lot of us are always
> connected (using screen or irc), so we get your messages even if we might=
 be
> away from our computers, and are slow to respond)
>
> Marcus
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev@lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst-dev/attachments/20080407/1=
441240f/attachment.htm
From ema_zep at libero.it  Wed Apr  9 07:08:07 2008
From: ema_zep at libero.it (Emanuele Zeppieri)
Date: Wed Apr  9 07:08:17 2008
Subject: [Catalyst-dev] Possible bug in Catalyst-Devel-1.05 [Patch]
Message-ID: <47FC5D47.8000706@libero.it>

Good morning!

Marcus,

is the following (line 622) in Helper.pm correct?

[% name %]->plugins(qw/-Debug ConfigLoader Static::Simple/);

since there is no "plugins" method in Catalyst.pm <=3D 5.7012 ...

If I understand correctly, according to the /new style/, it should =

instead be:

__PACKAGE__->setup(qw/-Debug ConfigLoader Static::Simple/);

In case I'm right, the attached patch does just that.

Cheers,
Emanuele
-------------- next part --------------
--- Helper.pm	2008-04-07 11:55:12.000000000 +0200
+++ Helper.pm.new	2008-04-09 07:17:21.014000000 +0200
@@ -619,8 +619,6 @@
 =

 use parent qw/Catalyst/;
 =

-[% name %]->plugins(qw/-Debug ConfigLoader Static::Simple/);
-
 our $VERSION =3D '0.01';
 =

 # Configure the application. =

@@ -635,7 +633,7 @@
 __PACKAGE__->config( name =3D> '[% name %]' );
 =

 # Start the application
-__PACKAGE__->setup;
+__PACKAGE__->setup(qw/-Debug ConfigLoader Static::Simple/);
 =

 =

 =3Dhead1 NAME
From marcus at nordaaker.com  Wed Apr  9 07:20:29 2008
From: marcus at nordaaker.com (Marcus Ramberg)
Date: Wed Apr  9 07:20:37 2008
Subject: [Catalyst-dev] Possible bug in Catalyst-Devel-1.05 [Patch]
In-Reply-To: <47FC5D47.8000706@libero.it>
References: <47FC5D47.8000706@libero.it>
Message-ID: <E4E58692-E815-4705-9E9C-9FD03505BB00@nordaaker.com>

n 9. april. 2008, at 08.08, Emanuele Zeppieri wrote:
> Good morning!
>
> Marcus,
>
> is the following (line 622) in Helper.pm correct?
>
> [% name %]->plugins(qw/-Debug ConfigLoader Static::Simple/);
>
> since there is no "plugins" method in Catalyst.pm <= 5.7012 ...
>
> If I understand correctly, according to the /new style/, it should  
> instead be:
>
> __PACKAGE__->setup(qw/-Debug ConfigLoader Static::Simple/);
>
> In case I'm right, the attached patch does just that.
>

Thanks Emanuele.

Not sure how that slipped through :( 1.06 on it's way to CPAN.

Marcus




From jon at jrock.us  Wed Apr  9 17:48:45 2008
From: jon at jrock.us (Jonathan Rockway)
Date: Wed Apr  9 17:48:49 2008
Subject: [Catalyst-dev] Possible bug in Catalyst-Devel-1.05 [Patch]
In-Reply-To: <47FC5D47.8000706@libero.it> (Emanuele Zeppieri's message of
	"Wed, 09 Apr 2008 08:08:07 +0200")
References: <47FC5D47.8000706@libero.it>
Message-ID: <87skxvynwy.fsf@bar.jrock.us>

* On Wed, Apr 09 2008, Emanuele Zeppieri wrote:
> Good morning!
>
> Marcus,
>
> is the following (line 622) in Helper.pm correct?
>
> [% name %]->plugins(qw/-Debug ConfigLoader Static::Simple/);
>
> since there is no "plugins" method in Catalyst.pm <= 5.7012 ...
>
> If I understand correctly, according to the /new style/, it should
> instead be:
>
> __PACKAGE__->setup(qw/-Debug ConfigLoader Static::Simple/);
>
> In case I'm right, the attached patch does just that.
>
> Cheers,
> Emanuele
> --- Helper.pm	2008-04-07 11:55:12.000000000 +0200
> +++ Helper.pm.new	2008-04-09 07:17:21.014000000 +0200
> @@ -619,8 +619,6 @@
>  
>  use parent qw/Catalyst/;
>  
> -[% name %]->plugins(qw/-Debug ConfigLoader Static::Simple/);
> -

Where did this come from anyway?  "use parent" looks like a change for
the Moose branch, but svn log doesn't reveal anything interesting.

Regards,
Jonathan Rockway

-- 
print just => another => perl => hacker => if $,=$"

From ema_zep at libero.it  Wed Apr  9 19:26:42 2008
From: ema_zep at libero.it (Emanuele Zeppieri)
Date: Wed Apr  9 19:26:50 2008
Subject: [Catalyst-dev] Possible bug in Catalyst-Devel-1.05 [Patch]
In-Reply-To: <87skxvynwy.fsf@bar.jrock.us>
References: <47FC5D47.8000706@libero.it> <87skxvynwy.fsf@bar.jrock.us>
Message-ID: <47FD0A62.6040208@libero.it>

Jonathan Rockway wrote:

> * On Wed, Apr 09 2008, Emanuele Zeppieri wrote:
>> Good morning!
>>
>> Marcus,
>>
>> is the following (line 622) in Helper.pm correct?
>>
>> [% name %]->plugins(qw/-Debug ConfigLoader Static::Simple/);
>>
>> since there is no "plugins" method in Catalyst.pm <= 5.7012 ...
>>
>> If I understand correctly, according to the /new style/, it should
>> instead be:
>>
>> __PACKAGE__->setup(qw/-Debug ConfigLoader Static::Simple/);
>>
>> In case I'm right, the attached patch does just that.
>>
>> Cheers,
>> Emanuele
>> --- Helper.pm	2008-04-07 11:55:12.000000000 +0200
>> +++ Helper.pm.new	2008-04-09 07:17:21.014000000 +0200
>> @@ -619,8 +619,6 @@
>>  
>>  use parent qw/Catalyst/;
>>  
>> -[% name %]->plugins(qw/-Debug ConfigLoader Static::Simple/);
>> -
> 
> Where did this come from anyway?  "use parent" looks like a change for
> the Moose branch, but svn log doesn't reveal anything interesting.

I'm afraid you're asking the wrong person, I'm not a committer ;-)
I can just point you to this previous message from Marcus:
http://lists.scsys.co.uk/pipermail/catalyst-dev/2008-April/001104.html

Cheers,
Emanuele.

From diment at gmail.com  Sat Apr 26 12:03:43 2008
From: diment at gmail.com (Kieren Diment)
Date: Sat Apr 26 12:03:52 2008
Subject: [Catalyst-dev] RFC, docs reorg, again
Message-ID: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com>

Please consider this idea:

Ditch the Catalyst::Manual dist, move everhthing that's not the  
tutorial back into Catalyst::Devel, and make a separate  
Catalyst::Manual::Tutorial dist.

Votes please.

From jshirley at gmail.com  Sat Apr 26 18:10:26 2008
From: jshirley at gmail.com (J. Shirley)
Date: Sat Apr 26 18:10:30 2008
Subject: [Catalyst-dev] RFC, docs reorg, again
In-Reply-To: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com>
References: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com>
Message-ID: <756703690804261010o7b5a48a7h4563a50c69e6cf4e@mail.gmail.com>

On Sat, Apr 26, 2008 at 4:03 AM, Kieren Diment <diment@gmail.com> wrote:
> Please consider this idea:
>
>  Ditch the Catalyst::Manual dist, move everhthing that's not the tutorial
> back into Catalyst::Devel, and make a separate Catalyst::Manual::Tutorial
> dist.
>
>  Votes please.
>
>  _______________________________________________
>  Catalyst-dev mailing list
>  Catalyst-dev@lists.scsys.co.uk
>  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>

+1.

Doubly so if that means people can install the docs from cpan...

From omega at palle.net  Sat Apr 26 22:55:12 2008
From: omega at palle.net (Andreas Marienborg)
Date: Sat Apr 26 22:55:17 2008
Subject: [Catalyst-dev] RFC, docs reorg, again
In-Reply-To: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com>
References: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com>
Message-ID: <50BC4555-2A8B-4EE2-8250-028958C8C6CA@palle.net>


On Apr 26, 2008, at 1:03 PM, Kieren Diment wrote:

> Please consider this idea:
>
> Ditch the Catalyst::Manual dist, move everhthing that's not the  
> tutorial back into Catalyst::Devel, and make a separate  
> Catalyst::Manual::Tutorial dist.
>
> Votes please.

+1, esp if this means that there will no longer be a Catalyst/ 
Manual.pm file in both dists.

It's confusing to have it both places, and makes it harder to find I  
think. If this means releasing Catalyst::Runtime a bit more often,  
with nothing but doc fixes, then so be it.

- andreas

From jon at jrock.us  Sun Apr 27 09:05:37 2008
From: jon at jrock.us (Jonathan Rockway)
Date: Sun Apr 27 09:05:39 2008
Subject: [Catalyst-dev] RFC, docs reorg, again
In-Reply-To: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com> (Kieren Diment's
	message of "Sat, 26 Apr 2008 21:03:43 +1000")
References: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com>
Message-ID: <87skx7wwmm.fsf@bar.jrock.us>

* On Sat, Apr 26 2008, Kieren Diment wrote:
> Please consider this idea:
>
> Ditch the Catalyst::Manual dist, move everhthing that's not the
> tutorial back into Catalyst::Devel, and make a separate
> Catalyst::Manual::Tutorial dist.
>
> Votes please.

-1.  We don't want doc fixes to have any relationship to bugfixes.
Changing the version number of the dist just to fix typos is a bad
idea.

-- 
print just => another => perl => hacker => if $,=$"

From diment at gmail.com  Sun Apr 27 10:58:17 2008
From: diment at gmail.com (Kieren Diment)
Date: Sun Apr 27 10:58:34 2008
Subject: [Catalyst-dev] RFC, docs reorg, again
In-Reply-To: <87skx7wwmm.fsf@bar.jrock.us>
References: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com>
	<87skx7wwmm.fsf@bar.jrock.us>
Message-ID: <609C380F-4A66-43AA-BF87-885DB35241B5@gmail.com>


On 27 Apr 2008, at 18:05, Jonathan Rockway wrote:

> * On Sat, Apr 26 2008, Kieren Diment wrote:
>> Please consider this idea:
>>
>> Ditch the Catalyst::Manual dist, move everhthing that's not the
>> tutorial back into Catalyst::Devel, and make a separate
>> Catalyst::Manual::Tutorial dist.
>>
>> Votes please.
>
> -1.  We don't want doc fixes to have any relationship to bugfixes.
> Changing the version number of the dist just to fix typos is a bad
> idea.
>

I agree, yet I disagree. I feel that in an ideal world, docs and code  
and cpan should all be completely separate from each other.   
Unfortunately, I feel that we're in some kind of non-ideal world  
where we're in some non-ideal distance between these three points.   
All I'm trying to do is iterate to the correct distance between the  
three vertices of the triangle O_o.

Please consider revising your vote here.

(n.b. I realise that core people are the only ones who actually get  
votes that count, but as with the democratic primaries in the states,  
it's a brave super-delegate who goes far against the flow).


From pagaltzis at gmx.de  Sun Apr 27 16:31:14 2008
From: pagaltzis at gmx.de (Aristotle Pagaltzis)
Date: Sun Apr 27 16:31:19 2008
Subject: [Catalyst-dev] Re: RFC, docs reorg, again
In-Reply-To: <87skx7wwmm.fsf@bar.jrock.us>
References: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com>
	<87skx7wwmm.fsf@bar.jrock.us>
Message-ID: <20080427153114.GA19658@klangraum.plasmasturm.org>

* Jonathan Rockway <jon@jrock.us> [2008-04-27 10:10]:
> * On Sat, Apr 26 2008, Kieren Diment wrote:
> > Please consider this idea:
> >
> > Ditch the Catalyst::Manual dist, move everhthing that's not
> > the tutorial back into Catalyst::Devel, and make a separate
> > Catalyst::Manual::Tutorial dist.
> >
> > Votes please.
> 
> -1.  We don't want doc fixes to have any relationship to
> bugfixes. Changing the version number of the dist just to fix
> typos is a bad idea.

I would agree if we were talking about Catalyst::Runtime.
Stability is crucial for that distro. But I don?t know that
Catalyst::Devel needs to be stable to the same extent.

Personally, I like the idea. Then Task::Catalyst::Tutorial
could be rolled into Catalyst::Manual::Tutorial also.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

From mb at cattlegrid.info  Sun Apr 27 19:22:22 2008
From: mb at cattlegrid.info (Michele Beltrame)
Date: Sun Apr 27 19:19:37 2008
Subject: [Catalyst-dev] RFC, docs reorg, again
In-Reply-To: <50BC4555-2A8B-4EE2-8250-028958C8C6CA@palle.net>
References: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com>
	<50BC4555-2A8B-4EE2-8250-028958C8C6CA@palle.net>
Message-ID: <20080427182221.GA13045@nowhere.ebau.it>

Hi!

> +1, esp if this means that there will no longer be a Catalyst/Manual.pm 
> file in both dists.

...which also makes Gentoo package manage complain (non fatally) when
installing packages.

Michele.

-- 
Michele Beltrame
http://www.cattlegrid.info/
ICQ 76660101 - MSN mb@italpro.net

From darren at darrenduncan.net  Sun Apr 27 20:12:38 2008
From: darren at darrenduncan.net (Darren Duncan)
Date: Sun Apr 27 20:13:10 2008
Subject: [Catalyst-dev] RFC, docs reorg, again
In-Reply-To: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com>
References: <968F4977-C883-49BA-A805-E553DC45A5CD@gmail.com>
Message-ID: <4814D026.8070602@darrenduncan.net>

Kieren Diment wrote:
> Please consider this idea:
> 
> Ditch the Catalyst::Manual dist, move everhthing that's not the tutorial 
> back into Catalyst::Devel, and make a separate 
> Catalyst::Manual::Tutorial dist.
> 
> Votes please.

My own take on this is that once documentation for a project becomes 
massive, it is best to move most of it into a separate distribution.  So 
just minimal introduction and API documentation should be with the code, 
and full blown manuals and tutorials should be separate.

So my own vote is for whatever situation keeps just some basic API and info 
references with the code and keeps manuals and tutorials separate from code.

Furthermore, I vote that there should not be any duplicate package names; 
each distribution should have distinct package names only.

Furthermore, I also agree with keeping the developer-only code separate 
from the code also needed for deployment

I also practice this with my Muldis database projects.  I have at least 3 
separate distributions, the first being the Muldis D language spec (all 
documentation), the second being the Muldis Rosetta reference 
implementation of that spec (mostly code plus some API docs), the third 
being for a manual or tutorial or what have you (all documentation).  Each 
of these has a root file named Muldis::D and Muldis::Rosetta and all the 
other files are beneath those namespaces.  All the documentation is POD and 
is installable like any code.

Note that, while every one of my POD-only files has a VERSION block near 
the top with NAME, as per Perl Best Practices, I discovered that the CPAN 
indexer doesn't currently get version info from those, and so my root file 
in those cases is actually a .pm file that contains nothing but a 
corresponding Perl package declaration with $VERSION, and nothing else, so 
that the indexer does the right thing when at least the distro as a whole, 
knowing when it has been updated and so forth.

-- Darren Duncan

From fat.perl.hacker at gmail.com  Mon Apr 28 00:56:31 2008
From: fat.perl.hacker at gmail.com (Paul Cain)
Date: Mon Apr 28 00:56:34 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
Message-ID: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>

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@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

From diment at gmail.com  Mon Apr 28 02:13:00 2008
From: diment at gmail.com (Kieren Diment)
Date: Mon Apr 28 02:13:13 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
Message-ID: <D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>

comments inline


On 28 Apr 2008, at 09:56, Paul Cain wrote:
>
> Paul Cain
>
> fat.perl.hacker@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);

Better to say that there's no accepted practice of framework for  
providing gui installers for catalyst apps.


> this module intends to help
> standardize setup by providing a generic GUI for all or most of them.

perhaps change this to something like: "by providing 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.
>

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.

perhaps with a nice little thing at the end of the gui installer that  
shows you the command line options you could have used at the end of  
the wizard.

>
>
>  *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.

Replace with:  "CatalystX::Installer uses the  with the Movable Type  
setup wizard as inspiration for its 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.

replace with : "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 adding the file "script/myapp_setup.pl" to the
> template for Catalyst programs. For example:
>
> $ catalyst MyApp
>

I think what's more likely to be that first you make the skeleton:

catalyst.pl MyApp

then you invoke a script to invoke the installer separately:

catalystx-installer [options]

do this from MyApp's home directory, and you use the Makefile.PL to  
work out that a.  you are actually in a catalyst app's home dir, b.   
what you want in the installer,

> 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.
>

I'll leave marcus to comment on the technical details above

Your schedule below is out of whack.  if the grant is accepted, it  
will commence on the 1st of June.  You can of course start gathering  
feedback from now though.

> *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
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev@lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

From zzbbyy at gmail.com  Mon Apr 28 06:26:43 2008
From: zzbbyy at gmail.com (Zbigniew Lukasiak)
Date: Mon Apr 28 06:26:47 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
Message-ID: <d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>

On Mon, Apr 28, 2008 at 3:13 AM, Kieren Diment <diment@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.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

From diment at gmail.com  Mon Apr 28 07:11:24 2008
From: diment at gmail.com (Kieren Diment)
Date: Mon Apr 28 07:11:31 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
Message-ID: <DA2E6947-D3EE-4C55-9A0B-BE0AA2F6377A@gmail.com>


On 28 Apr 2008, at 15:26, Zbigniew Lukasiak wrote:

> On Mon, Apr 28, 2008 at 3:13 AM, Kieren Diment <diment@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.
>

Here's the picture i was trying to paint:

admin goes to set up application on host with the installer gui.

At the end, the installer remembers how it set stuff up, and presents  
the admin with a screen "you can set this up on another host with the  
command catalystx-installer --options ...

which the admin can then tweak to do subsequent installation on other  
hosts without having to do very much work at all.

Is that not sane?


From omega at palle.net  Mon Apr 28 07:57:39 2008
From: omega at palle.net (Andreas Marienborg)
Date: Mon Apr 28 07:57:41 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
Message-ID: <F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>


On Apr 28, 2008, at 7:26 AM, Zbigniew Lukasiak wrote:

> On Mon, Apr 28, 2008 at 3:13 AM, Kieren Diment <diment@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

- andreas


From diment at gmail.com  Mon Apr 28 08:14:13 2008
From: diment at gmail.com (Kieren Diment)
Date: Mon Apr 28 08:14:31 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
	<F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
Message-ID: <A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>


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@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 :-)

From omega at palle.net  Mon Apr 28 12:09:14 2008
From: omega at palle.net (Andreas Marienborg)
Date: Mon Apr 28 12:09:18 2008
Subject: [Catalyst-dev] Catalyst::View::TT and PROVIDERS
Message-ID: <1CD9897F-3D36-41BF-9CC2-D6D8AA45C565@palle.net>

Hello

I try to use Template::Provider::Encoding, to make usage of utf-8  
encoded templates easier. The problem is that to make it work nicely,  
I need to do something with Catalyst::View::TT. The issue is that I  
need to tell the PROVIDER about INCLUDE_PATH, but the INCLUDE_PATH  
gets set after all the PROVIDERS are done initializing, and thus any  
$c->stash->{additional_template_paths} gets lost.

I have created a patch (attached) that extends the View::TT PROVIDERS  
config-key a bit, and also reorders the constructor a little.

The net benefit is that the PROVIDER initialization code now can copy  
config-keys from the main config, and when it copies INCLUDE_PATH, it  
copies the one with the coderef, which ends in  
additional_template_paths working when I use the Encoding-provider.

- andreas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: catalyst-view-tt-reorder.diff
Type: application/octet-stream
Size: 5362 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/catalyst-dev/attachments/20080428/d5aadf0b/catalyst-view-tt-reorder.obj
-------------- next part --------------



From fat.perl.hacker at gmail.com  Mon Apr 28 17:57:29 2008
From: fat.perl.hacker at gmail.com (Paul Cain)
Date: Mon Apr 28 17:57:32 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
	<F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
	<A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>
Message-ID: <a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>

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@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@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@lists.scsys.co.uk
>  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>

From fat.perl.hacker at gmail.com  Tue Apr 29 06:56:27 2008
From: fat.perl.hacker at gmail.com (Paul Cain)
Date: Tue Apr 29 06:56:32 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
	<F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
	<A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>
	<a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>
Message-ID: <a31f34090804282256o32b698a8n957486157e2026df@mail.gmail.com>

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@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@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@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@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@lists.scsys.co.uk
>  >  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>  >
>

From SvenDowideit at home.org.au  Tue Apr 29 08:55:00 2008
From: SvenDowideit at home.org.au (Sven Dowideit)
Date: Tue Apr 29 08:55:11 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <a31f34090804282256o32b698a8n957486157e2026df@mail.gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
	<F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
	<A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>
	<a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>
	<a31f34090804282256o32b698a8n957486157e2026df@mail.gmail.com>
Message-ID: <1209455700.29230.21.camel@quad.home.org.au>

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@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@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@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@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@lists.scsys.co.uk
> >  >  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
> >  >
> >
> 
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev@lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

From evdb at ecclestoad.co.uk  Tue Apr 29 09:05:54 2008
From: evdb at ecclestoad.co.uk (Edmund von der Burg)
Date: Tue Apr 29 09:05:57 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
	<F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
	<A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>
	<a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>
Message-ID: <f0145aa60804290105p4f9eceaw803a3e38244a2944@mail.gmail.com>

2008/4/28 Paul Cain <fat.perl.hacker@gmail.com>:
> 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.

This would mean that the command line system would be closely tied to
the GUI part. A change to the GUI might lead to a change in the
command line code too.

Better would be to have the command line and GUI produce a config file
(or similar) which is then used to actually do the installation. This
would decouple the two, and allow for other installation methods in
future.

However it is achieved having a simple way to install a Catalyst app
would be great - so good luck with this.

Cheers,
  Edmund.

From fat.perl.hacker at gmail.com  Tue Apr 29 22:49:04 2008
From: fat.perl.hacker at gmail.com (Paul Cain)
Date: Tue Apr 29 22:49:09 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <1209455700.29230.21.camel@quad.home.org.au>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
	<F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
	<A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>
	<a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>
	<a31f34090804282256o32b698a8n957486157e2026df@mail.gmail.com>
	<1209455700.29230.21.camel@quad.home.org.au>
Message-ID: <a31f34090804291449x122b0762p1c2a036f84f356f5@mail.gmail.com>

Sven,

Your idea is certainly intriguing; it would be nice to create a
generic web deployment module, perhaps as a sister module to
CatalystX::Installer that uses a lot of the same code base.

Unfortunately, I'm a full time student right now, and I will only have
time to do this during the summer(although hopefully I will still be
able to maintain it afterwards). Mainly I want to keep the scope of
this program fairly narrow to assure that I can get it done on time.
However, things get ahead of schedule, I may consider adding more
functionality either to CatalystX::Installer or branching it off into
new module.

Paul Cain

On Tue, Apr 29, 2008 at 2:55 AM, Sven Dowideit <SvenDowideit@home.org.au> wrote:
> 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@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@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@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@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@lists.scsys.co.uk
>  > >  >  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>  > >  >
>  > >
>  >
>  > _______________________________________________
>  > Catalyst-dev mailing list
>  > Catalyst-dev@lists.scsys.co.uk
>  > http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>
>  _______________________________________________
>  Catalyst-dev mailing list
>  Catalyst-dev@lists.scsys.co.uk
>  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>

From fat.perl.hacker at gmail.com  Tue Apr 29 22:49:15 2008
From: fat.perl.hacker at gmail.com (Paul Cain)
Date: Tue Apr 29 22:49:19 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <f0145aa60804290105p4f9eceaw803a3e38244a2944@mail.gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
	<F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
	<A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>
	<a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>
	<f0145aa60804290105p4f9eceaw803a3e38244a2944@mail.gmail.com>
Message-ID: <a31f34090804291449y672dc56fi757a90517cfc5520@mail.gmail.com>

Edmund,

I see what you mean about the GUI and command line becoming closely
tied if I use WWW::Mechanize. Part of the  problem with command line
options is that parsing them can be a painful experience. However, I
was thinking that if I enforced a strict, uniform way to pass command
line options, it would make thing much simpler.

Each command line option would have a corresponding form entry, but
the order in which the command line options are passed would not be
significant. For example:

script/myapp_setup.pl --password="mypass"  --username="admin"
--db_location="/tmp"

If the options are generated by the script/myapp_install.pl after it
runs, like Kieren suggested above, it would save the user from having
to learn the rules for command line options.

It's something to think about.

Paul Cain

On Tue, Apr 29, 2008 at 3:05 AM, Edmund von der Burg
<evdb@ecclestoad.co.uk> wrote:
> 2008/4/28 Paul Cain <fat.perl.hacker@gmail.com>:
>
> > 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.
>
>  This would mean that the command line system would be closely tied to
>  the GUI part. A change to the GUI might lead to a change in the
>  command line code too.
>
>  Better would be to have the command line and GUI produce a config file
>  (or similar) which is then used to actually do the installation. This
>  would decouple the two, and allow for other installation methods in
>  future.
>
>  However it is achieved having a simple way to install a Catalyst app
>  would be great - so good luck with this.
>
>  Cheers,
>   Edmund.
>
>
>
>  _______________________________________________
>  Catalyst-dev mailing list
>  Catalyst-dev@lists.scsys.co.uk
>  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>

From diment at gmail.com  Tue Apr 29 22:53:01 2008
From: diment at gmail.com (Kieren Diment)
Date: Tue Apr 29 22:53:09 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <a31f34090804291449y672dc56fi757a90517cfc5520@mail.gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
	<F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
	<A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>
	<a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>
	<f0145aa60804290105p4f9eceaw803a3e38244a2944@mail.gmail.com>
	<a31f34090804291449y672dc56fi757a90517cfc5520@mail.gmail.com>
Message-ID: <6AB3DF49-E6AF-4D3E-B434-335BDF52A8B2@gmail.com>


On 30 Apr 2008, at 07:49, Paul Cain wrote:

> Part of the  problem with command line
> options is that parsing them can be a painful experience. However, I
> was thinking that if I enforced a strict, uniform way to pass command
> line options, it would make thing much simpler.

You remove all the pain from this by using Getopt::Std or  
Getopt::Long (or both).

From fat.perl.hacker at gmail.com  Wed Apr 30 00:16:29 2008
From: fat.perl.hacker at gmail.com (Paul Cain)
Date: Wed Apr 30 00:16:33 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <6AB3DF49-E6AF-4D3E-B434-335BDF52A8B2@gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
	<F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
	<A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>
	<a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>
	<f0145aa60804290105p4f9eceaw803a3e38244a2944@mail.gmail.com>
	<a31f34090804291449y672dc56fi757a90517cfc5520@mail.gmail.com>
	<6AB3DF49-E6AF-4D3E-B434-335BDF52A8B2@gmail.com>
Message-ID: <a31f34090804291616y66b7f53fq66d41da78759cb92@mail.gmail.com>

After reviewing Getopt::Long some more, I think it would fit the task
quite well.

Since the deadline is almost here, I'm going to go ahead and submit my
application now. However, I still want to keep discussing the details
of this project.

On Tue, Apr 29, 2008 at 4:53 PM, Kieren Diment <diment@gmail.com> wrote:
>
>  On 30 Apr 2008, at 07:49, Paul Cain wrote:
>
>
> > Part of the  problem with command line
> > options is that parsing them can be a painful experience. However, I
> > was thinking that if I enforced a strict, uniform way to pass command
> > line options, it would make thing much simpler.
> >
>
>  You remove all the pain from this by using Getopt::Std or Getopt::Long (or
> both).
>
>
>
>  _______________________________________________
>  Catalyst-dev mailing list
>  Catalyst-dev@lists.scsys.co.uk
>  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>

From SvenDowideit at home.org.au  Wed Apr 30 01:46:53 2008
From: SvenDowideit at home.org.au (Sven Dowideit)
Date: Wed Apr 30 01:47:04 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <a31f34090804291449x122b0762p1c2a036f84f356f5@mail.gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
	<F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
	<A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>
	<a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>
	<a31f34090804282256o32b698a8n957486157e2026df@mail.gmail.com>
	<1209455700.29230.21.camel@quad.home.org.au>
	<a31f34090804291449x122b0762p1c2a036f84f356f5@mail.gmail.com>
Message-ID: <1209516413.4923.14.camel@quad.home.org.au>

fair enough :)

now that you have the idea in mind, you may make design decisions that
will make it easier - from there refactoring to separate teh Catalyst
specifics and the web generics may well be easier.

Cheers

Sven


On Tue, 2008-04-29 at 16:49 -0500, Paul Cain wrote:
> Sven,
> 
> Your idea is certainly intriguing; it would be nice to create a
> generic web deployment module, perhaps as a sister module to
> CatalystX::Installer that uses a lot of the same code base.
> 
> Unfortunately, I'm a full time student right now, and I will only have
> time to do this during the summer(although hopefully I will still be
> able to maintain it afterwards). Mainly I want to keep the scope of
> this program fairly narrow to assure that I can get it done on time.
> However, things get ahead of schedule, I may consider adding more
> functionality either to CatalystX::Installer or branching it off into
> new module.
> 
> Paul Cain
> 
> On Tue, Apr 29, 2008 at 2:55 AM, Sven Dowideit <SvenDowideit@home.org.au> wrote:
> > 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@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@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@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@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@lists.scsys.co.uk
> >  > >  >  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
> >  > >  >
> >  > >
> >  >
> >  > _______________________________________________
> >  > Catalyst-dev mailing list
> >  > Catalyst-dev@lists.scsys.co.uk
> >  > http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
> >
> >  _______________________________________________
> >  Catalyst-dev mailing list
> >  Catalyst-dev@lists.scsys.co.uk
> >  http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
> >
> 
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev@lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

From omega at palle.net  Wed Apr 30 06:20:29 2008
From: omega at palle.net (Andreas Marienborg)
Date: Wed Apr 30 06:20:35 2008
Subject: [Catalyst-dev] Proposal to the Perl Foundation for
	CatalystX::Installer
In-Reply-To: <6AB3DF49-E6AF-4D3E-B434-335BDF52A8B2@gmail.com>
References: <a31f34090804271656q371d0981nc59cbbb368e1c6b9@mail.gmail.com>
	<D54B7333-3C09-48D1-BB57-CAB022B47775@gmail.com>
	<d36a60910804272226y1aa5a9ffv6950fa19098a2ce3@mail.gmail.com>
	<F4A8D5F7-E779-4F5C-84B3-F79FEA214D5A@palle.net>
	<A67FC944-3F66-434D-9540-6BE0849DFD95@gmail.com>
	<a31f34090804280957y65da7f0lbcd0354e70f204fc@mail.gmail.com>
	<f0145aa60804290105p4f9eceaw803a3e38244a2944@mail.gmail.com>
	<a31f34090804291449y672dc56fi757a90517cfc5520@mail.gmail.com>
	<6AB3DF49-E6AF-4D3E-B434-335BDF52A8B2@gmail.com>
Message-ID: <1BFAAC5D-84CB-4E26-A7E0-6409DA1871A4@palle.net>


On Apr 29, 2008, at 11:53 PM, Kieren Diment wrote:

>
> On 30 Apr 2008, at 07:49, Paul Cain wrote:
>
>> Part of the  problem with command line
>> options is that parsing them can be a painful experience. However, I
>> was thinking that if I enforced a strict, uniform way to pass command
>> line options, it would make thing much simpler.
>
> You remove all the pain from this by using Getopt::Std or  
> Getopt::Long (or both).

Or Getopt::Euclid

- andreas


From marcus at nordaaker.com  Wed Apr 30 11:53:11 2008
From: marcus at nordaaker.com (Marcus Ramberg)
Date: Wed Apr 30 11:53:17 2008
Subject: [Catalyst-dev] Catalyst::View::TT and PROVIDERS
In-Reply-To: <1CD9897F-3D36-41BF-9CC2-D6D8AA45C565@palle.net>
References: <1CD9897F-3D36-41BF-9CC2-D6D8AA45C565@palle.net>
Message-ID: <CB7076A4-08D6-4286-8B07-5D518CC3DA97@nordaaker.com>


On 28. april. 2008, at 13.09, Andreas Marienborg wrote:

> Hello
>
> I try to use Template::Provider::Encoding, to make usage of utf-8  
> encoded templates easier. The problem is that to make it work  
> nicely, I need to do something with Catalyst::View::TT. The issue is  
> that I need to tell the PROVIDER about INCLUDE_PATH, but the  
> INCLUDE_PATH gets set after all the PROVIDERS are done initializing,  
> and thus any $c->stash->{additional_template_paths} gets lost.
>
> I have created a patch (attached) that extends the View::TT  
> PROVIDERS config-key a bit, and also reorders the constructor a  
> little.
>
> The net benefit is that the PROVIDER initialization code now can  
> copy config-keys from the main config, and when it copies  
> INCLUDE_PATH, it copies the one with the coderef, which ends in  
> additional_template_paths working when I use the Encoding-provider.

Applied. Catalyst-View-TT 0.27 on it's way to CPAN.

Marcus