> -----Original Message-----
> From: Stas Bekman [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 25, 2001 9:10 AM
> To: Geoffrey Young
> Cc: '[EMAIL PROTECTED] '
> Subject: Re: :Table::get implementation?
>
>
> Geoffrey Young wrote:
>
> >>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.
>
>
> that's how it should be but I don't see this happening. The thing you
> are talking about is supposed to happen in
> modperl_config.c:modperl_config_dir_merge right? But this
> function has
> no access to modperl_config_srv_t, so it doesn't do the merge
> with any
> settings done on the server level.
well, speaking from my limited knowledge of how 1.3 works, if you made the
directives per-dir directives then they don't need to be handled at the
per-server level - Apache merges per-dir directives that appear on a
per-server level into a null config that is handled by the per-dir merge so
everything works out.
I haven't had the tuits to investigate the 2.0 architecture, so maybe it's
different. maybe Doug has some insight here as well...
>
> Still let's say that this works, run-time can always call
> $s->dir_config->set(foo => $bar), how a call to
> $r->dir_config can know
> about this change in the same request?
Am I missing something in the new API? $s->dir_config? I don't see the
need for dir_config on a per-server level. that's not how it is in 1.x and
it works just fine...
>
>
> > sorry if I'm missing some design considerations already
> discussed - I'm
> > still trying to catch up with my email after a vacation...
>
>
> Nope, we didn't discuss this before.
>
> Hope you'd a nice vacation :)
sort of...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
