module multi-config strategy

[martin langhoff <ma...@scim.net>]

hi list,

	i'm about to start writing the first of a series of internal modules,
aimed at handling common features among sites we develop. Like, let's
say, a 'latest news' box or a product guide/database. 

	Now, the idea is to have one codebase, written in a module that serves
all of our sites. Each site should have its own (rather complex) config.
Each and every subroutine must know in which context it's being called,
and I don't really want to pass the config as a parameter to every
damned sub. 

	Currently, I keep the configs as a global hash inside the module,
that's good when you've got one module per implementation. I won't scale
further justlike that. 

	Maybe I should have a hash inside the module, with the $ENV{HTTP_HOST}
or $ENV{'SERVER_NAME'} as key and the configs as values. Maybe this same
setup in a mysql table. But that'd allow only one implementation of each
module per domain. And I think that maybe I'll someday need, say, 2
product guides (under different brands) in the same site / page. 

	So that's not 'THE' way. Maybe something intermediate. But I don't
really know how. Does anyone want to share his views on this? 

	Maybe I could build a wrapper module, that manages the configs and sets
them up in the environment. That'd be nice to post in CPAN. 



martin

Re: module multi-config strategy

[martin langhoff <ma...@scim.net>]

Perrin,

	you mean that I can actually set my environment per virtual-host?

	that's encouraging in the one-implementation per site scenario. Now I
does block any use of persistent variables, unless I store them in a
RDBMS or in the 'Globals' module you mentioned. It could really be a
module that just exported references to internal hashes. I'm starting to
like it. 

	A module that exported persistent hashes (not across server restarts,
just across requests ... short lived persistence). Maybe it could be
loading the 'config' hashes from disk every once in a while, say every
10 seconds, to be able to reconfig without restarting. And the ability
to commit a given hash ('config') to disk to make it permanent.

	mmmh. an idea is shaping here in my tiny head ... anyone care to
comment?



martin

Perrin Harkins wrote:
> 
> You can have a module full of globals that is different for each site (it
> doesn't have to go in the same directory as your other shared code), or
> you can put things in httpd.conf with PerlSetVar and read them with
> $r->dir_config(), which allows a separate configuration for each virtual
> host.
> 
> - Perrin

Re: module multi-config strategy

[Perrin Harkins <pe...@primenet.com>]

On Mon, 24 Jul 2000, martin langhoff wrote:
> Now, the idea is to have one codebase, written in a module that serves
> all of our sites. Each site should have its own (rather complex)
> config. Each and every subroutine must know in which context it's
> being called, and I don't really want to pass the config as a
> parameter to every damned sub.

You can have a module full of globals that is different for each site (it
doesn't have to go in the same directory as your other shared code), or
you can put things in httpd.conf with PerlSetVar and read them with
$r->dir_config(), which allows a separate configuration for each virtual
host.

- Perrin