Re: [mp2] finfo collisions with Apache::compat
Geoffrey Young wrote: Stas Bekman wrote: Geoff, any chance we can get this one resolved? As we may make a new release soonish, we can't have this collision in Apache::compat and APR::Finfo get out from the dev release. I really don't know the answer to this. the new finfo API is a proper interface, and I don't see removing it just to appease the compat layer, especially since it's just exposing a problem that many compat methods have. I've never suggested that. I'm just pushing to get the conflict resolved before we release a new version. what about a new namespace? instead of finfo_old make everyone using compat do this my $r = Apache::compat($r); then $r->finfo would be certain to call Apache::compat::finfo. actually, I meant Apache::compat->new($r) but you get the idea :) It's a cool idea, but it 1) requires users to change their code, whereas for most case they don't need to with the current Apache::compat 2) it won't work for functions which aren't invoked on $r I still think this is a solution worthy of investigation. I just don't care about 1) and I think we might be able to work around 2) somewhat - I've created subclasses that return my own objects for $r->connection, so I would assume we can do the same for $r->server, $r->parsed_uri, etc. which leaves only stuff like Apache->server_root_relative. we can probably come up with something clever there too :) This still requires heavy modifications in the user code. If they do so, they should just move to the new API. The idea behind compat.pm is to have to run the code unmodified (so neither my renaming idea fits in). So if we already require users to change their code, let's just rename the method. How about adding _mp1 postfix for those methods that collide? I don't think that's a good idea at all - you might as well not have a compat layer at all then. in the short term, though, I'd be in favor of removing Apache::compat::finfo() if the smoke failures are bothersome - finfo() just isn't all that popular (unfortunately). The smoke is only showing that users may have the same issues in their code, besides not letting to smoke real problems out. If there is no co-existence solution it needs to be removed. But not having a compat layer at all is not a good solution. I suggest to move all those colliding methods to a different package and let people use it on their own risk. Or an alternative approach is to keep Apache::compat but have an import method which will enable the colliding functions on demand. So if you'd want finfo, you'd say: use Apache::compat qw(Apache::RequestRec::finfo); and it'll build this compat method. There will be a big warnings suggesting possible collisions with the 2.0 API. At the same time the harmless compat API will work as before. __ Stas BekmanJAm_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]
[mp2] raising the default startup timeout
As our test suite grows it takes more and more time to start the server, the worker mpm almost always fail to start within 60 secs on my machine (which is pretty fast). And now we get reports from users who run prefork and it takes 68 secs to start. So I'd suggest to make the default per server mpm and not one for all and go with 120 secs for prefork and 180 worker/winnt. If it sometimes takes more than 90 secs to start worker on my machine, I can see it hitting 3 minutes on a slower machine. Ideally there should be no timeout at all, if we could deterministically detect a failure in the server startup, but we weren't quite successful at it so far. __ Stas BekmanJAm_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]
Re: [mp2] finfo collisions with Apache::compat
>> I still think this is a solution worthy of investigation. I just >> don't care >> about 1) and I think we might be able to work around 2) somewhat - I've >> created subclasses that return my own objects for $r->connection, so I >> would >> assume we can do the same for $r->server, $r->parsed_uri, etc. which >> leaves >> only stuff like Apache->server_root_relative. we can probably come up >> with >> something clever there too :) > > > This still requires heavy modifications in the user code. If they do so, > they should just move to the new API. The idea behind compat.pm is to > have to run the code unmodified (so neither my renaming idea fits in). hmm. I don't see "heavy modification." what I'm suggesting is that Apache::compat be a subclass of Apache. thus, like any true subclass, everything remains the same for the user save the constructor. the modification would now be two lines use Apache::compat; my $r = Apache::compat->new($r); rather than just use Apacahe::compat; I don't see heavy modification here at all for anything that comes from $r, $c, or $s. where it gets tricky are the class methods like server_root_relative(), and yes, those would be problematic for this approach. and, of course, it's lots of work for us to rewrite it all, too :) and I really don't have much of an interest in the compat layer anyway, so I'm not all that motivated to work on it. > The smoke is only showing that users may have the same issues in their > code, besides not letting to smoke real problems out. in the case of compat there definitely will be conflicts whether it shows up in smoke or not. that's been well established, right? this is why I don't think that smoke is that big a deal with compat - we know the issues are there, so fixing finfo specifically is just a short-term solution. what really needs to happen is that we need to fix the compat layer so that it won't cause the problem for users. that, or just live with smoke driving known issues to the surface. > > If there is no co-existence solution it needs to be removed. But not > having a compat layer at all is not a good solution. I suggest to move > all those colliding methods to a different package and let people use it > on their own risk. Or an alternative approach is to keep Apache::compat > but have an import method which will enable the colliding functions on > demand. So if you'd want finfo, you'd say: > > use Apache::compat qw(Apache::RequestRec::finfo); > > and it'll build this compat method. There will be a big warnings > suggesting possible collisions with the 2.0 API. > > At the same time the harmless compat API will work as before. yeah, I think we had discussed that too, and it seems like a decent approach. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] raising the default startup timeout
Stas Bekman wrote: > As our test suite grows it takes more and more time to start the server, > the worker mpm almost always fail to start within 60 secs on my machine > (which is pretty fast). And now we get reports from users who run > prefork and it takes 68 secs to start. yikes. I got 49 seconds last night, so I guess it is pretty close > > So I'd suggest to make the default per server mpm and not one for all > and go with 120 secs for prefork and 180 worker/winnt. If it sometimes > takes more than 90 secs to start worker on my machine, I can see it > hitting 3 minutes on a slower machine. I'm in favor so long as the change is mod_perl specific - no need to burden the entire apache community with perl's bloat :) --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] mod_perl test suite fails
On Tue, 2003-12-09 at 18:57, Stas Bekman wrote:
> Which probably means that your perl POSIX implementation is broken.
Wed Dec 10 12:15:18 [EMAIL PROTECTED]:~> su -
Password:
[EMAIL PROTECTED] root]# perl -le 'require POSIX; POSIX::setgid(99) or die
"failed to run: $@";'
[EMAIL PROTECTED] root]# perl -le 'require POSIX; POSIX::setuid(65534) or
die "failed to setuid: $@"; print -r q{/root} && -w _ && -x _ ? q{OK} :
q{NOK}; '
OK
Regards
Volker
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] raising the default startup timeout
Geoffrey Young wrote: Stas Bekman wrote: As our test suite grows it takes more and more time to start the server, the worker mpm almost always fail to start within 60 secs on my machine (which is pretty fast). And now we get reports from users who run prefork and it takes 68 secs to start. yikes. I got 49 seconds last night, so I guess it is pretty close And that's on Unloaded machine. Try to do some heave things at the same time (e.g. run another test suite or compilation) and the startup time will double. So I'd suggest to make the default per server mpm and not one for all and go with 120 secs for prefork and 180 worker/winnt. If it sometimes takes more than 90 secs to start worker on my machine, I can see it hitting 3 minutes on a slower machine. I'm in favor so long as the change is mod_perl specific - no need to burden the entire apache community with perl's bloat :) Of course. We have the new argument -startup_timeout (which is still misplaced), which we will set if it wasn't set already, just like maxclients. __ Stas BekmanJAm_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]
Re: [mp2] raising the default startup timeout
> Of course. We have the new argument -startup_timeout (which is still > misplaced), which we will set if it wasn't set already, just like > maxclients. actually, I no longer think it's misplaced - I want the persistence that placing it where it is gives. that is, if I need to raise it for my particular box, I don't want to be required to raise it every time I call t/TEST. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] finfo collisions with Apache::compat
Geoffrey Young wrote: I still think this is a solution worthy of investigation. I just don't care about 1) and I think we might be able to work around 2) somewhat - I've created subclasses that return my own objects for $r->connection, so I would assume we can do the same for $r->server, $r->parsed_uri, etc. which leaves only stuff like Apache->server_root_relative. we can probably come up with something clever there too :) This still requires heavy modifications in the user code. If they do so, they should just move to the new API. The idea behind compat.pm is to have to run the code unmodified (so neither my renaming idea fits in). hmm. I don't see "heavy modification." what I'm suggesting is that Apache::compat be a subclass of Apache. thus, like any true subclass, everything remains the same for the user save the constructor. the modification would now be two lines use Apache::compat; my $r = Apache::compat->new($r); rather than just use Apacahe::compat; I don't see heavy modification here at all for anything that comes from $r, $c, or $s. where it gets tricky are the class methods like server_root_relative(), and yes, those would be problematic for this approach. and, of course, it's lots of work for us to rewrite it all, too :) and I really don't have much of an interest in the compat layer anyway, so I'm not all that motivated to work on it. Yes, it's too much work and it won't work for non-methods. The smoke is only showing that users may have the same issues in their code, besides not letting to smoke real problems out. in the case of compat there definitely will be conflicts whether it shows up in smoke or not. that's been well established, right? this is why I don't think that smoke is that big a deal with compat - we know the issues are there, so fixing finfo specifically is just a short-term solution. what really needs to happen is that we need to fix the compat layer so that it won't cause the problem for users. that, or just live with smoke driving known issues to the surface. I guess you don't realize what the problem is with smoke. These known issues prevent from running smoke to discover unknown ones. It's only finfo that gets on the way. If there is no co-existence solution it needs to be removed. But not having a compat layer at all is not a good solution. I suggest to move all those colliding methods to a different package and let people use it on their own risk. Or an alternative approach is to keep Apache::compat but have an import method which will enable the colliding functions on demand. So if you'd want finfo, you'd say: use Apache::compat qw(Apache::RequestRec::finfo); and it'll build this compat method. There will be a big warnings suggesting possible collisions with the 2.0 API. At the same time the harmless compat API will work as before. yeah, I think we had discussed that too, and it seems like a decent approach. OK, let's do it then. __ Stas BekmanJAm_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]
Re: [mp2] raising the default startup timeout
Geoffrey Young wrote: Of course. We have the new argument -startup_timeout (which is still misplaced), which we will set if it wasn't set already, just like maxclients. actually, I no longer think it's misplaced - I want the persistence that placing it where it is gives. that is, if I need to raise it for my particular box, I don't want to be required to raise it every time I call t/TEST. So you suggest to make it a configuration option (which it happens to be now). Fine with me. __ Stas BekmanJAm_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]
Re: [Patch mp2] PerlSections namespace
On Tue, 2003-12-09 at 17:44, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > It's been a long time that perl sections have been having trouble with
> > recursive inclusion. This has been discussed before and has to do with
> > the fact that all PerlSections are evaluated in the same namespace
> > Apache::ReadSections.
> >
> > The following patch follows a similar design than ModPerl::Registry,
> > putting each block in it's own namespace, based on filename &
> > lineno.
>
> Coolio ;)
>
> > This now prevents infinite-recursion problems and makes $Includes from
> > within sections work fine.
> >
> > There is still one little problem left with this, people will not be
> > able to put stuff directly in the Apache::ReadSections namespace
> > themselves. I do have a plan for fixing that as well in a subsequent
> > patch.
>
> You 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
sections, so I wanted to fix a problem at a time, even though if it
temporarely introduces another little different problem.
Now that we are sticking sections in their own distinct
namespaces, it means that for people who put stuff directly in
Apache::ReadConfig, I can think of 2 ways of handling it.
1. Apache::PerlSections defaults to reading from the unique package and
also process the contents of Apache::ReadConfig.
Problem with this (same as it is right now) , is that since people just
add to the %Apache::ReadConfig:: namespace, each time a block
ends, the sum of its content is fed back into apache, so you get
warnings and errors, since directives are processed multiple times.
2. Leave %Apache::ReadConfig:: alone until right after the config phase
and feed it to Apache::PerlSections in one go
Problem with this that processing of Apache::ReadConfig (for modules and
code that push into it themselves) will be delayed at the very end and
might break existing things that expects it to be processed at the end
of the block that ran...
I dunno about anybody else, but I prefer solution 2, but what do you
think?
> > As usual, look at it and tell me if it breaks more stuff than it fixes
> > ;-)
>
> I suppose it was a proof of concept, since you need to fix quite a few style
> things (long lines, some missing indent, missing spaces around ops).
Yes, you supposed right ;-) I just wanted review on it.
> > I had to introduce a function in mod_perl_util.c, modperl_file2package,
> > that makes a package-safe name from a filepath, so maybe it could be
> > exposed and used by ModPerl::Registry as well?
>
> Good idea. I've just introduced the opposite function package2filename (to fix
> the problems in modperl_mgv). I'm not sure it fits registrycooker, since it
> doesn't drop /, whereas your function does, collapsing everything into a
> single word. It may have problems, since these two distinct names will map
> into the same namespace:
>
> foo/barbaz
> foobar/baz
>
> so the concept of dropping / is wrong. You need to replace each '/' with '::'.
I am not dropping it, just if it's at the beginning, for example
foo/barbaz => foo_barbaz
foobar/baz => foobar_baz
//foobar/baz => foobar_baz
/foobar/baz => foobar_baz
>
> modperl_file2package has its own problems ;) a stash name can't start with
> numerical and ':'. See below:
Can't start with a numerical? Oh, I'll make sure I check for that as
well then.
> [...]
> > +#define MP_VALID_PKG_CHAR(c) (isalnum(c)||c==':'||c=='_')
> > +static const char *modperl_file2package(apr_pool_t *p, const char *file)
> > +{
> > +char *package;
> > +char *c;
> > +
> > +c = package = apr_pcalloc(p, strlen(file));
> > +
> > +/* First, skip invalid prefix characters */
> > +while (!MP_VALID_PKG_CHAR(*file)) {
> > +file++;
> > +}
>
> You need here:
>
> #define MP_VALID_PKG_FIRST_CHAR(c) (isalpha(c) || c == '_')
>
> /* First, skip invalid prefix characters */
> while (!MP_VALID_PKG_FIRST_CHAR(*file)) {
>file++;
> }
>
> Neither you can have a single ':' in the package name (or triple, etc), so you
> should check that they come in doubles...
Well, even simpler, if I just remove ':' from the allowed characters,
I'll avoid that problem (and keep the string the same size or smaller)
So
C:\FooBar\Baz\Bof => C_FooBar_Baz_Bof
> __
> Stas BekmanJAm_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
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make
Re: [mp2] raising the default startup timeout
On Wed, 2003-12-10 at 01:04, Stas Bekman wrote:
> As our test suite grows it takes more and more time to start the server, the
> worker mpm almost always fail to start within 60 secs on my machine (which is
> pretty fast). And now we get reports from users who run prefork and it takes
> 68 secs to start.
I constantly hover between 55-65 seconds, so my local copy has been
patched for 90secs for quite a while already ;-)
> So I'd suggest to make the default per server mpm and not one for all and go
> with 120 secs for prefork and 180 worker/winnt. If it sometimes takes more
> than 90 secs to start worker on my machine, I can see it hitting 3 minutes on
> a slower machine.
>
> Ideally there should be no timeout at all, if we could deterministically
> detect a failure in the server startup, but we weren't quite successful at it
> so far.
Well, until we can do that reliably, I am completely in favor of a
high(er) timeout
> __
> Stas BekmanJAm_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]
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [Patch mp2] PerlSections namespace
> > 2. Leave %Apache::ReadConfig:: alone until right after the config phase > and feed it to Apache::PerlSections in one go > > Problem with this that processing of Apache::ReadConfig (for modules and > code that push into it themselves) will be delayed at the very end and > might break existing things that expects it to be processed at the end > of the block that ran... > > I dunno about anybody else, but I prefer solution 2, but what do you > think? in all the stuff I've done with adding directly to the ReadConfig namespace, I don't _think_ I've ever relied on the exact placement of the directives. so, it _sounds_ ok to me (at the moment :) --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
Philippe M. Chiasson wrote:
On Tue, 2003-12-09 at 17:44, Stas Bekman wrote:
Philippe M. Chiasson wrote:
It's been a long time that perl sections have been having trouble with
recursive inclusion. This has been discussed before and has to do with
the fact that all PerlSections are evaluated in the same namespace
Apache::ReadSections.
The following patch follows a similar design than ModPerl::Registry,
putting each block in it's own namespace, based on filename &
lineno.
Coolio ;)
This now prevents infinite-recursion problems and makes $Includes from
within sections work fine.
There is still one little problem left with this, people will not be
able to put stuff directly in the Apache::ReadSections namespace
themselves. I do have a plan for fixing that as well in a subsequent
patch.
You 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
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?
Now that we are sticking sections in their own distinct
namespaces, it means that for people who put stuff directly in
Apache::ReadConfig, I can think of 2 ways of handling it.
1. Apache::PerlSections defaults to reading from the unique package and
also process the contents of Apache::ReadConfig.
Problem with this (same as it is right now) , is that since people just
add to the %Apache::ReadConfig:: namespace, each time a block
ends, the sum of its content is fed back into apache, so you get
warnings and errors, since directives are processed multiple times.
2. Leave %Apache::ReadConfig:: alone until right after the config phase
and feed it to Apache::PerlSections in one go
Problem with this that processing of Apache::ReadConfig (for modules and
code that push into it themselves) will be delayed at the very end and
might break existing things that expects it to be processed at the end
of the block that ran...
I dunno about anybody else, but I prefer solution 2, but what do you
think?
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
, so that they need to switch 'package Apache::ReadConfig;' to start
feeding things into the config.
[...]
I had to introduce a function in mod_perl_util.c, modperl_file2package,
that makes a package-safe name from a filepath, so maybe it could be
exposed and used by ModPerl::Registry as well?
Good idea. I've just introduced the opposite function package2filename (to fix
the problems in modperl_mgv). I'm not sure it fits registrycooker, since it
doesn't drop /, whereas your function does, collapsing everything into a
single word. It may have problems, since these two distinct names will map
into the same namespace:
foo/barbaz
foobar/baz
so the concept of dropping / is wrong. You need to replace each '/' with '::'.
I am not dropping it, just if it's at the beginning, for example
foo/barbaz => foo_barbaz
foobar/baz => foobar_baz
//foobar/baz => foobar_baz
/foobar/baz => foobar_baz
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
modperl_file2package has its own problems ;) a stash name can't start with
numerical and ':'. See below:
Can't start with a numerical? Oh, I'll make sure I check for that as
well then.
It can start only with _ or alpha
[...]
+#define MP_VALID_PKG_CHAR(c) (isalnum(c)||c==':'||c=='_')
+static const char *modperl_file2package(apr_pool_t *p, const char *file)
+{
+char *package;
+char *c;
+
+c = package = apr_pcalloc(p, strlen(file));
+
+/* First, skip invalid prefix characters */
+while (!MP_VALID_PKG_CHAR(*file)) {
+file++;
+}
You need here:
#define MP_VALID_PKG_FIRST_CHAR(c) (isalpha(c) || c == '_')
/* First, skip invalid prefix characters */
while (!MP_VALID_PKG_FIRST_CHAR(*file)) {
file++;
}
Neither you can have a single ':' in the package name (or triple, etc), so you
should check that they come in doubles...
Well, even simpler, if I just remove ':' from the allowed characters,
I'll avoid that problem (and keep the string the same size or smaller)
So
C:\FooBar\Baz\Bof => C_FooBar_Baz_Bof
I think you shouldn't replace groups o
Re: [Patch mp2] PerlSections namespace
> 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 , so that they need to
> switch 'package Apache::ReadConfig;' to start feeding things into the
> config.
no, you can also add entries directly to the Apache::ReadConfig namespace in
order to add configuration data.
package Apache::Foo;
$Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
sub handler { };
now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
there are a few modules on CPAN that do this, IIRC.
it's similar to Apache->server->add_config() in mp2, but I've found that
method really not worth the trouble - it's goverened by overrides, so you
can never really trust that it will add the configuration data you pipe into it.
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
Geoffrey Young wrote:
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 , so that they need to
switch 'package Apache::ReadConfig;' to start feeding things into the
config.
no, you can also add entries directly to the Apache::ReadConfig namespace in
order to add configuration data.
package Apache::Foo;
$Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
sub handler { };
now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
there are a few modules on CPAN that do this, IIRC.
it's similar to Apache->server->add_config() in mp2, but I've found that
method really not worth the trouble - it's goverened by overrides, so you
can never really trust that it will add the configuration data you pipe into it.
That's exactly why people do *not* need to work directly with
Apache::ReadConfig - they have Apache->server->add_config() (and we are
talking about mp2). If people can achieve the same thing without using
Apache::ReadConfig, I think it should be completely deprecated, which avoids
the problem altogether. That's why I wanted to know if there are cases where
it's absolutely needed and you can't go without it.
I think this case:
package Foo;
my $whatever = whatever();
package Apache::ReadConfig;
$User = $whatever;
can now become:
package Foo;
my $whatever = whatever();
Apache->server->add_config("$User $whatever");
Though it's probably not going to be simple for creating more complex config
directives, e.g complex containers. Can you think of a good solution for that
case?
__
Stas BekmanJAm_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]
Re: [Patch mp2] PerlSections namespace
>> it's similar to Apache->server->add_config() in mp2, but I've found that
>> method really not worth the trouble - it's goverened by overrides, so you
>> can never really trust that it will add the configuration data you
>> pipe into it.
>
>
> That's exactly why people do *not* need to work directly with
> Apache::ReadConfig - they have Apache->server->add_config() (and we are
> talking about mp2). If people can achieve the same thing without using
> Apache::ReadConfig, I think it should be completely deprecated, which
> avoids the problem altogether. That's why I wanted to know if there are
> cases where it's absolutely needed and you can't go without it.
well, as I said, add_config() can't accomplish the same thing. in fact,
every time I've tried to use add_config() the way I want I haven't been able
to. not that it's not useful for some things, but it's not useful for the
level of trickery that I'm used to being able to do with ReadConfig.
>
> I think this case:
>
>
> package Foo;
> my $whatever = whatever();
> package Apache::ReadConfig;
> $User = $whatever;
>
>
> can now become:
>
>
> package Foo;
> my $whatever = whatever();
> Apache->server->add_config("$User $whatever");
>
this is entirely different than what I'm talking about.
>
> Though it's probably not going to be simple for creating more complex
> config directives, e.g complex containers. Can you think of a good
> solution for that case?
I haven't tried add_config for containers, but it's interface seems
straightforward enough (when it works at all).
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
On Wed, 2003-12-10 at 11:49, Stas Bekman wrote: > Philippe M. Chiasson wrote: > > On Tue, 2003-12-09 at 17:44, Stas Bekman wrote: > > > >>Philippe M. Chiasson wrote: > >> > >>>It's been a long time that perl sections have been having trouble with > >>>recursive inclusion. This has been discussed before and has to do with > >>>the fact that all PerlSections are evaluated in the same namespace > >>>Apache::ReadSections. > >>> > >>>The following patch follows a similar design than ModPerl::Registry, > >>>putting each block in it's own namespace, based on filename & > >>>lineno. > >> > >>Coolio ;) > >> > >> > >>>This now prevents infinite-recursion problems and makes $Includes from > >>>within sections work fine. > >>> > >>>There is still one little problem left with this, people will not be > >>>able to put stuff directly in the Apache::ReadSections namespace > >>>themselves. I do have a plan for fixing that as well in a subsequent > >>>patch. > >> > >>You 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 > > 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? You are quite right about this. Especially with a release on the 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 section problems as well. > > Now that we are sticking sections in their own distinct > > namespaces, it means that for people who put stuff directly in > > Apache::ReadConfig, I can think of 2 ways of handling it. > > > 1. Apache::PerlSections defaults to reading from the unique package and > > also process the contents of Apache::ReadConfig. > > > > Problem with this (same as it is right now) , is that since people just > > add to the %Apache::ReadConfig:: namespace, each time a block > > ends, the sum of its content is fed back into apache, so you get > > warnings and errors, since directives are processed multiple times. > > > > 2. Leave %Apache::ReadConfig:: alone until right after the config phase > > and feed it to Apache::PerlSections in one go > > > > Problem with this that processing of Apache::ReadConfig (for modules and > > code that push into it themselves) will be delayed at the very end and > > might break existing things that expects it to be processed at the end > > of the block that ran... > > > > I dunno about anybody else, but I prefer solution 2, but what do you > > think? > > 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 > , 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. 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. > [...] > > >>>I had to introduce a function in mod_perl_util.c, modperl_file2package, > >>>that makes a package-safe name from a filepath, so maybe it could be > >>>exposed and used by ModPerl::Registry as well? > >> > >>Good idea. I've just introduced the opposite function package2filename (to fix > >>the problems in modperl_mgv). I'm not sure it fits registrycooker, since it > >>doesn't drop /, whereas your function does, collapsing everything into a > >>single word. It may have problems, since these two distinct names will map > >>into the same namespace: > >> > >>foo/barbaz > >>foobar/baz > >> > >>so the concept of dropping / is wrong. You need to replace each '/' with '::'. > > > > > > I am not dropping it, just if it's at the beginning, for example > > > > foo/barbaz => foo_barbaz > > foobar/baz => foobar_baz > > > > //foobar/baz => foobar_baz > > /foobar/baz => foobar_baz > > 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 shoul
Re: [Patch mp2] PerlSections namespace
On Wed, 2003-12-10 at 11:51, Geoffrey Young wrote:
> > 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 , so that they need to
> > switch 'package Apache::ReadConfig;' to start feeding things into the
> > config.
>
> no, you can also add entries directly to the Apache::ReadConfig namespace in
> order to add configuration data.
>
> package Apache::Foo;
> $Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
> sub handler { };
>
> now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
> there are a few modules on CPAN that do this, IIRC.
Yes, but this has always been partially broken as it is.
For example:
package Apache::Foo;
$Apache::ReadConfig::Alias = qw(/some/path /some/alias);
If you only do :
PerlModule Apache::Foo
and have no sections in your httpd.conf, that code will not
happen
If you have more than one section, you'll get warnings about
re-defining an Alias directive for the same location, as the content of
Apache::ReadConfig:: will be read and processed for every block.
> it's similar to Apache->server->add_config() in mp2, but I've found that
> method really not worth the trouble - it's goverened by overrides, so you
> can never really trust that it will add the configuration data you pipe into it.
Can you give me one such example ?
I can imagine a section in a block might not (yet)
have access to the right Apache::Server object to add it's configuration
to... Is that what you mean ?
> --Geoff
>
>
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [Patch mp2] PerlSections namespace
Geoffrey Young wrote:
it's similar to Apache->server->add_config() in mp2, but I've found that
method really not worth the trouble - it's goverened by overrides, so you
can never really trust that it will add the configuration data you
pipe into it.
That's exactly why people do *not* need to work directly with
Apache::ReadConfig - they have Apache->server->add_config() (and we are
talking about mp2). If people can achieve the same thing without using
Apache::ReadConfig, I think it should be completely deprecated, which
avoids the problem altogether. That's why I wanted to know if there are
cases where it's absolutely needed and you can't go without it.
well, as I said, add_config() can't accomplish the same thing. in fact,
every time I've tried to use add_config() the way I want I haven't been able
to. not that it's not useful for some things, but it's not useful for the
level of trickery that I'm used to being able to do with ReadConfig.
What do you mean, it can't? It just feeds the config sections as if you have
written them in httpd.conf. I fail to see how it fails. The issue is that you
completely lose the usefulness of using perl structures to accomplish that.
I think this case:
package Foo;
my $whatever = whatever();
package Apache::ReadConfig;
$User = $whatever;
can now become:
package Foo;
my $whatever = whatever();
Apache->server->add_config("$User $whatever");
this is entirely different than what I'm talking about.
I know. I was just showing a different, unrelated case where we need to deal
with Apache::ReadConfig.
Though it's probably not going to be simple for creating more complex
config directives, e.g complex containers. Can you think of a good
solution for that case?
I haven't tried add_config for containers, but it's interface seems
straightforward enough (when it works at all).
Yes, but you will need to manually concatenate the config section, you can't
use perl structures for that.
__
Stas BekmanJAm_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]
Re: [Patch mp2] PerlSections namespace
On Wed, 2003-12-10 at 12:06, Stas Bekman wrote:
> Geoffrey Young wrote:
> >>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 , so that they need to
> >>switch 'package Apache::ReadConfig;' to start feeding things into the
> >>config.
> >
> >
> > no, you can also add entries directly to the Apache::ReadConfig namespace in
> > order to add configuration data.
> >
> > package Apache::Foo;
> > $Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
> > sub handler { };
> >
> > now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
> > there are a few modules on CPAN that do this, IIRC.
> >
> > it's similar to Apache->server->add_config() in mp2, but I've found that
> > method really not worth the trouble - it's goverened by overrides, so you
> > can never really trust that it will add the configuration data you pipe into it.
>
> That's exactly why people do *not* need to work directly with
> Apache::ReadConfig - they have Apache->server->add_config() (and we are
> talking about mp2). If people can achieve the same thing without using
> Apache::ReadConfig, I think it should be completely deprecated, which avoids
> the problem altogether. That's why I wanted to know if there are cases where
> it's absolutely needed and you can't go without it.
Like I just said, one problem is that from within a block, you
would possibly need to have access to the current server object.
Otherwise you'll be adding your configuration to the topmost server, and
not the current VHost your section is in.
But if that's the only issue preventing getting rid of
Apache::ReadConfig alltogether, I would be more than happy to make the
right server object accessible from within sections in a global
variable or sth similar.
> I think this case:
>
>
>package Foo;
>my $whatever = whatever();
>package Apache::ReadConfig;
>$User = $whatever;
>
>
> can now become:
>
>
>package Foo;
>my $whatever = whatever();
>Apache->server->add_config("$User $whatever");
>
>
> Though it's probably not going to be simple for creating more complex config
> directives, e.g complex containers. Can you think of a good solution for that
> case?
Could probably make use of a subclass of Apache::PerlSections for this.
PerlModule Foo
package Foo;
use Apache::PerlSections::Processor;
$User = 'gozer';
$Location{"/this"} = { "Options" => "+ExecCGI"};
Apache::PerlSections::Processor->readnamespace("Foo");
Or something like that.
> __
> Stas BekmanJAm_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
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [Patch mp2] PerlSections namespace
>> well, as I said, add_config() can't accomplish the same thing. in fact, >> every time I've tried to use add_config() the way I want I haven't >> been able >> to. not that it's not useful for some things, but it's not useful for >> the >> level of trickery that I'm used to being able to do with ReadConfig. > > > What do you mean, it can't? It just feeds the config sections as if you > have written them in httpd.conf. I fail to see how it fails. add_config() is equivalent to an .htaccess file - whatever overrides govern .htaccess files' ability to have directives inserted into the configuration will apply to add_config() as well. that is very different from ReadConfig's blind addition of directives into the config. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
>>package Apache::Foo;
>>$Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
>>sub handler { };
>>
>>now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
>>there are a few modules on CPAN that do this, IIRC.
>
>
> Yes, but this has always been partially broken as it is.
>
> For example:
>
> package Apache::Foo;
> $Apache::ReadConfig::Alias = qw(/some/path /some/alias);
>
>
> If you only do :
>
> PerlModule Apache::Foo
>
> and have no sections in your httpd.conf, that code will not
> happen
really? I'll have to check that :)
>
> If you have more than one section, you'll get warnings about
> re-defining an Alias directive for the same location, as the content of
> Apache::ReadConfig:: will be read and processed for every block.
ugh, that's bad.
>
>
>
>>it's similar to Apache->server->add_config() in mp2, but I've found that
>>method really not worth the trouble - it's goverened by overrides, so you
>>can never really trust that it will add the configuration data you pipe into it.
>
>
> Can you give me one such example ?
as I mentioned in reply to stas, add_config is equivalent to .htaccess files
- so wherever .htaccess files are disallowed, so are add_config() additions.
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
Philippe M. Chiasson wrote:
[...]
You 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
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?
You are quite right about this. Especially with a release on the
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 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
, 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 BekmanJAm_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]
Re: [Patch mp2] PerlSections namespace
Geoffrey Young wrote: well, as I said, add_config() can't accomplish the same thing. in fact, every time I've tried to use add_config() the way I want I haven't been able to. not that it's not useful for some things, but it's not useful for the level of trickery that I'm used to being able to do with ReadConfig. What do you mean, it can't? It just feeds the config sections as if you have written them in httpd.conf. I fail to see how it fails. add_config() is equivalent to an .htaccess file - whatever overrides govern .htaccess files' ability to have directives inserted into the configuration will apply to add_config() as well. that is very different from ReadConfig's blind addition of directives into the config. I thought it was behaving differently when called at the server startup. In any case it's not pretty so it's not a good substitute... __ Stas BekmanJAm_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]
Re: [Patch mp2] PerlSections namespace
On Wed, 2003-12-10 at 12:53, Geoffrey Young wrote:
> >>package Apache::Foo;
> >>$Apache::ReadConfig::PerlFixupHandler = "Apache::Foo";
> >>sub handler { };
> >>
> >>now, PerlModule Apache::Foo automatically installs a PerlFixupHandler :)
> >>there are a few modules on CPAN that do this, IIRC.
> >
> >
> > Yes, but this has always been partially broken as it is.
> >
> > For example:
> >
> > package Apache::Foo;
> > $Apache::ReadConfig::Alias = qw(/some/path /some/alias);
> >
> >
> > If you only do :
> >
> > PerlModule Apache::Foo
> >
> > and have no sections in your httpd.conf, that code will not
> > happen
>
> really? I'll have to check that :)
>
> >
> > If you have more than one section, you'll get warnings about
> > re-defining an Alias directive for the same location, as the content of
> > Apache::ReadConfig:: will be read and processed for every block.
>
> ugh, that's bad.
Yes, and when someone reported that problem in mp2, I thought I could
look at mp1 to see how that problem was avoided, but it wasn't. When I
ported sections from mp1 to mp2, I sadly ported a lot of existing
problems/bugs as well ;-p
Time to fix it all, I guess.
> >
> >
> >
> >>it's similar to Apache->server->add_config() in mp2, but I've found that
> >>method really not worth the trouble - it's goverened by overrides, so you
> >>can never really trust that it will add the configuration data you pipe into it.
> >
> >
> > Can you give me one such example ?
>
> as I mentioned in reply to stas, add_config is equivalent to .htaccess files
> - so wherever .htaccess files are disallowed, so are add_config() additions.
Really? That's not quite DWIMy, isn't it? I would have thought
differently. That would be a bit sucky.
It's strange though, because sections (and processing of
Apache::ReadConfig is dont thru add_config I believe).
Are you sure about this ?
> --Geoff
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [Patch mp2] PerlSections namespace
>> add_config() is equivalent to an .htaccess file - whatever overrides >> govern >> .htaccess files' ability to have directives inserted into the >> configuration >> will apply to add_config() as well. that is very different from >> ReadConfig's blind addition of directives into the config. > > > I thought it was behaving differently when called at the server startup. > In any case it's not pretty so it's not a good substitute... looks like you're right. I tried to whip up some examples at startup but I couldn't find any. I guess the failures I'm remembering were request time, when I tried to inject "Requires valid-user" or something on-the-fly and was denied by AllowOverride none. so maybe at startup it's not a bad idea after all :) --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Patch mp2] PerlSections namespace
On Wed, 2003-12-10 at 14:14, Geoffrey Young wrote:
> >> add_config() is equivalent to an .htaccess file - whatever overrides
> >> govern
> >> .htaccess files' ability to have directives inserted into the
> >> configuration
> >> will apply to add_config() as well. that is very different from
> >> ReadConfig's blind addition of directives into the config.
> >
> >
> > I thought it was behaving differently when called at the server startup.
> > In any case it's not pretty so it's not a good substitute...
>
> looks like you're right. I tried to whip up some examples at startup but I
> couldn't find any. I guess the failures I'm remembering were request time,
> when I tried to inject "Requires valid-user" or something on-the-fly and was
> denied by AllowOverride none.
That does make sense at runtime indeed. You don't want any registry to
be able to define new aliases and all at runtime when AllowOverride is
none.
> so maybe at startup it's not a bad idea after all :)
So, does this mean that you don't have a specific objection against
deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
future in favor of ->add_config("User foo") ?
> --Geoff
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [Patch mp2] PerlSections namespace
Philippe M. Chiasson wrote:
so maybe at startup it's not a bad idea after all :)
So, does this mean that you don't have a specific objection against
deprecating (or tossing) direct access to %Apache::ReadConfig:: in the
future in favor of ->add_config("User foo") ?
The problem with add_config() is that it wants a string as if you've written
it in httpd.conf language. Taking an access to %Apache::ReadConfig:: away
takes away the ability to use perl structs to autovivify complex constructs.
e.g. how do you build a complex vhost with nested containers using add_config?
may be we could have an alternative method, accepting an SV (e.g. a hash ref
which represents a container) which perl will then convert to a string and
feed to add_config?
__
Stas BekmanJAm_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]
