> There is another performance issue with setvars I'm thinking about.
> Currently when you perform $r->dir_config I have to merge the
> directory
> and server configs and give you the new table. This may be very
> expensive. Now we could avoid this by doing a deeper merge at the
> configuration stage, but since we allow
> $s->dir_config->set|add the $s'
> vars can change and our merged version be wrong. So it sucks,
> performance wise of course, since we cannot pre-merge. I
> guess we should
> put a fat warning -- DO NOT Call $s->dir_config without arguments,
> unless you don't mind performance implications.
these issues should be handled separately, no? PerlSetVar is just another
config directive, so by the time you get to the PerlHeaderParser you ought
to have a fully populated table (done via normal directory merging).
whether elements are added to removed at runtime shouldn't require merging,
since you are just manipulating an existing and populated table.
sorry if I'm missing some design considerations already discussed - I'm
still trying to catch up with my email after a vacation...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
