Mark Stosberg wrote:
> On 2005-12-20, Michael Graham <[EMAIL PROTECTED]> wrote:
>
>>Before anyone gets too worried, I would like to point out that this
>>proposal would not require a core change to C::A, but could be
>>implemented with a plugin using the existing plugin system.
>
>
> It be a plugin, but I think the definition of a standard API for this
> belongs in the core. Since we are talking about a single (5 line? )
> optional method, I think it's reasonable to add there. It can still be
> ignored or overridden if you choose.
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.
Besides, if the config plugins stabilize their API and it works out great then
more discussion can be had on adding it to the core. If it ends up being a
disaster, oh well, no permanent damage to C::A (maybe just a few plugin authors
who have to deprecate an old APIs).
>> * need a clean way of dealing with config formats that don't support
>> hierarchical data structures.
>
>
> I see that happening like this: The session plugin declares:
>
> "You can configure me through your config file if you use one of the
> plugins that is powerful enough to support hierarchical data structures.
> Otherwise, configure me manually."
>
> In other words, if you want to stick with a less powerful config file
> system, you aren't any worse off than you are now.
I agree with this. There are tons of config systems that support hierarchical
data. If someone decides to not use one, they need to deal with that fact
themselves.
>> * plugins that want a database handle should be encouraged to look
>> to $self->dbh before they get their connection info from the
>> config file.
>
>
> Agreed. Also, supporting sub { $self->dbh } is nice when people /do/ use
> the explicit config interface. This keeps the handle from actually being
> created until it is needed, if at all.
>
>
>> * Any other computed config values that plugins typically need?
>
>
> Not that I can think of.
>
>
>> * It might be reasonable to allow multiple config 'providers'. For
>> instance having a 'root_dir' param available that all plugins can
>> rely on could be a really useful thing.
I think this idea definitely illustrates why this should not be in the core. Why
should C::A care about where your project is running? Sure your project might
care, but should C::A?
> 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.
--
Michael Peters
Developer
Plus Three, LP
---------------------------------------------------------------------
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]
