Ime Smits wrote:
>
> | Well, I would like to suggest that you consider including <!--#include
> | virtual--> in the Apache::ASP distribution, so that included files use the
> | same namespace. It doesn't make sense logically that include virtual
> | behaves differently from include file (other than the way the
> | filename/pathname is interpreted, of course).
>
> It does make sense to me, though. Consider one having very big (say 50k)
> include files being included from several other (say 100) scripts. Just
> sucking them in each script doing the include would cause *every* script
> growing by at least the size of the include. Now as Apache::ASP caches all
> compiled scripts, this would result in each httpd process growing by 50kB x
> 100 scripts = 5 MB, holding 98% redundant data.
>
If DynamicIncludes are turned on, then file includes are
compiled as subroutines, and executed as if $Response->Include()
were called. Without this setting, includes text are added
to the including scripts like you are saying.
But this does not solve the virtual includes problem. A virtual
include is supposed to be anything executed on the server,
not just files, but the output from anything like some C cgi,
or another .pl or so, and must therefore be processed as a
separate subrequest. This is what Apache::SSI does.
The problem here is that there is no way for the Apache::ASP
script to catch the output from the apache subrequest to
even try to compile it into its own script, even if you really
wanted to do this. So this is why this is stays a separate
feature to be handled by Apache::SSI, that it doesn't help
at all to inline it into Apache::ASP, except some small
performance benefit by not running the output through
Apache::Filter
-- Joshua
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
