Philippe M. Chiasson wrote: [...]
You are quite right about this. Especially with a release on theYou mean it will break their code. In which case I'd suggest not to commit this patch till you get it all ready.
Yeah, well, things are already broken quite a bit w/r to <Perl > sections, so I wanted to fix a problem at a time, even though if it temporarely introduces another little different problem.
Yes, but your change is going to introduce a new problem, and if it's not fixed by the time of the new release, it'll break people's code which worked fine with the previous release. Not too friendly, hey? And I think we should do a new release rsn. What do you think?
horizon. In that case, I'd lean towards solution #1, easily achieved by
having PerlSections iterate over symbols in the generated namespace AND
%Apache::ReadConfig on each pass. This ends up being just like before,
and would fix recursive <Perl > section problems as well.
What about doing #3 - at the end of each block feed it to Apache and somehow mark that block as processed, so it won't be rerun again? e.g. by moving the symbols into a special package, which is not ReadConfig?
I think you also have a problem of ordering thing. As you may end up with overriding order problem, no? I think 1 is safer and making it deprecated will eventually make the problem go away completely. Am I correct to say that people don't need to work directly with Apache::ReadConfig? I think the only place this is needed when people mix config with non-config perl code in <Perl>, so that they need to switch 'package Apache::ReadConfig;' to start feeding things into the config.
As far as I can tell, now that we have Apache::Server->add_config, I'd be more than happy to deprecate direct usage of the %Apache::ReadConfig:: namespace.
As you can see in the other sub-thread, it's not going to be simple.
Ordering as of today is still a problem anyways (in Location, VirtualHost and other containers). In mp1 we were using Tie::IxHash to work around this, and I am planning on doing the same thing in the near future to address that problem.
That's good.
OK, but I can still see how it it breaks. Consider:
foo-/baz => foo_baz foo/-baz => foo_baz
whereas this works:
foo-/baz => foo_::baz foo/-baz => foo::_baz
I think you shouldn't replace groups of chars with a single _, you must preserve the lent
Correct, I didn't realize that. One question I have though is for win32.
Would it be 100% safe to :
1. replace occurences of '/' and '\' (path separators) with '::'
careful here, as you have \\ too, you don't want to end up with ::::
2. replace non alphanumeric with '_'
if you assume 1:1, then yes (length doesn't change)
3. insure resulting package doesn't start with '::' or numeric
rather check that it starts with alpha or '_' ;)
I know File::Spec would be the nicest way of going around doing it:
my $name = join('::', File::Spec->splitpath($filename)); $name =~ s/[^a-zA-Z0-9]/_/g;
absolutely ;)
[...]
I don't think there is a good solution here, as you apply a lossful transformation. We have the same problem with registry, but nobody has ever complained, since most files include alphanumerics only.
So, can we agree on what will agree to be doing ? Then I'll be happy to write it, stick it in modperl_util.c, expose it thru ModPerl::Util (for registry) and use it for PerlSection's namespaces
I think your proposition above is fine. (it's the same as the alg used by RegistryCooker, just reproduce it from that perl code 1:1).
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
