> I wonder how many people actually take advantage of
> NameWithVirtualHost=1. seems that the PerlRun methodology (filenames)
> is a much cleaner solution that invites less problems/confusion.

No matter how many are using it has to be there. I guess the default one
can be done using inodes and not url/filename (remember the symlink
problem). I think there is no problem with vhs when using inode or
filename, right?

I think Apache::Registry should be configurable at compile time, rather
than manually crafted by users.

So one can tell:

Apache::Registry::config(cache_method => (inode|filename|uri),
                         stat_file    => 1|0,
                         ...
                        )
and make sure that Apache::Registry is loaded only after the configuration
is done, so it can be lego-built on the fly at compile time.

Of course we can make Apache::RegistryNG, simply configuring
Apache::Registry in a certain way, so users can re-use a set of pre-made
configurations and even then override things. I think that would be
beautiful.

I'm thinking about how to solve the __DATA__ and __END__ problems
(probably need to rewrite the source to skip these).

I guess the biggest problem to solve is somehow to avoid the closure
problem. Any ideas about that? Someone has posted a solution for this
problem, but if I remember correctly it wasn't very fast and clean.

What other problems we need to attack, that aren't solved in the current
version or just bothers some people? I guess the issue with globals. I
think we can tackle this with yet another config option, which will reset
all globals in the user namespace. Or would that be very slow? What
happens if we do that at the end of the request, rather at the beginning
of it?

_____________________________________________________________________
Stas Bekman              JAm_pH     --   Just Another mod_perl Hacker
http://stason.org/       mod_perl Guide  http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to