On 2005-12-20, Michael Peters <[EMAIL PROTECTED]> wrote:
>
> I'm actually leaning toward Graham's idea here that it just be in the
> plugins. I
> like the API but I'm not sure it's something that should be in the core. I
> know
> configuration is something pretty basic that every framework should have, but
> I
> don't see C::A as a framework... more as a framework for building frameworks.
In my v2 RFC I proposed a very minimum of code in the core:
sub config { return undef }
And that's just a convenience for plugin authors so they don't have to
check if the 'config' method exists, they can directly check
$self->config('key_i_want');
>> I want CGI::Apps to eventually have something like 'mark par'. Part of
>> 'mark par' conuld involve altering the configuration to adjust this.
>> Exactly how...I'll leave to someone else.
>
> Again, not something that I think should be in the core. This is definitely
> something that I don't want. PAR is neat, but not completely everything that I
> need.
>
> I'm much happier with something like the krang build/install system. If you
> need
> a binary for a specific platform, you just take the source, run the build
> script
> and viola! It even builds it's own apache/mod_perl/mod_ssl server with it, so
> you never have to worry about server configuration. Of course these binaries
> aren't cross-platform, but in reality neither are most PARs.
I don't see a need to put anything PAR specific in CGI/Application.pm
Rather, like Catalyst the logic would be mostly in Makefile.PL (or some
yet-to-exist helper script), and in Module::Install::CGIApp, which is
also separate.
So it should be easy to ignore PAR support if you want to, and there
should be performance penalty, etc for having these bits exist.
Mark
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
