Re: Another way to perhaps do this......
Wouldn't it be better to subclass Apache::SSI instead of HTML::Embperl::Syntax::SSI ? That part of it would be really easy - the hard part would be actually implementing the OAS directive actions. If you really only want to do SSI, then subclassing Apache::SSI is of course the easier and better way to go. If you already use Embperl or want the features of EmbperlObject together with SSI, extenting HTML::Embperl::Syntax::SSI offers far more possibilities Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: Another way to perhaps do this......
Gerald Richter [EMAIL PROTECTED] wrote: Wouldn't it be better to subclass Apache::SSI instead of HTML::Embperl::Syntax::SSI ? That part of it would be really easy - the hard part would be actually implementing the OAS directive actions. If you really only want to do SSI, then subclassing Apache::SSI is of course the easier and better way to go. If you already use Embperl or want the features of EmbperlObject together with SSI, extenting HTML::Embperl::Syntax::SSI offers far more possibilities Yes, absolutely - I wasn't sure whether the OP was looking for standalone SSI interpreting and extending, or whether he was going to use it in conjunction with something like Embperl. -Ken
Re: Another way to perhaps do this......
On Fri, 28 Sep 2001 16:40, Steven Boger wrote: I've been netsearching for hours. It's time to beg for help... My apache has a hacked mod_include that has a new directive, OAS: !--OAS SETUP=www.realmedia.com/Samples/lx.shtml@TopLeft,TopRight,BottomLeft, BottomRight-- !--OAS AD=BottomRight-- Can I somehow run those directives right from mod_perl If you have the Eagle book (if you don't you should get it), it talks about an Apache::SSI module on pg 94, and then shows you how to implement it. You will find a nicely packaged up Apache::SSI on CPAN by Ken Williams. I haven't used it myself, but it should do what you are looking for. You will have to hack this code to handle your OAS calls though... Cees
Re: Another way to perhaps do this...... / SSI
Hey Ken, You are probably right. Your Apache::SSI module looks quite simple to extend, although the same can be said for HTML::Embperl::Syntax. The reason I was working with the Embperl module, was that I was wanting to change !--#exec cgi=listsomething.cgi-- calls to something faster. I rewrote the cgi's in Embperl, but needed a fast way of including them without requiring the HTML guy to learn Embperl and have to rewrite all his pages... and Embperl.v2's new Syntax::SSI module fit the bill. Either way you get access to mod_perl... although if Apache::SSI is extended, its easier to share with other mod_perl folks I suppose... BTW, I did a couple of quick benchmarks. With the old mod_include system, page.shtml included headers, footers, and exec'd a CGI twice. On a production server (dual PIII-933 Mhz processors, SCSI, 512 MB) this resulted in 1.5 requests per second. By the end of the test (ApacheBench) the load was at 8 or 9. On my development system, I changed page.shtml in both places, so that !--#exec cgi=listsomething.cgi-- is now !--#include virtual=listsomething.epl--. This results in 13 requests/second. This is actually on my workstation, which is running PostgreSQL, MySQL, X, and KDE, all on a PIII-550 Mhz system with an IDE drive and 384 MB of memory. By the end of the test (ApacheBench), the load was still less then 1. Steven, by hacked mod_include, do you mean that you hacked mod_include to support the OAS directive, or that Real Media did this? Ken Williams wrote: Wim Steven, Wouldn't it be better to subclass Apache::SSI instead of HTML::Embperl::Syntax::SSI ? That part of it would be really easy - the hard part would be actually implementing the OAS directive actions. Wim Kerkhoff [EMAIL PROTECTED] wrote: Steven Boger wrote: I've been netsearching for hours. It's time to beg for help... My apache has a hacked mod_include that has a new directive, OAS: !--OAS SETUP=www.realmedia.com/Samples/lx.shtml@TopLeft,TopRight,BottomLeft, BottomRight-- !--OAS AD=BottomRight-- Can I somehow run those directives right from mod_perl Well... Since I've been spending several hours looking at the HTML::Embperl::Syntax::SSI module (Embperl.v2), I'm going to suggest that you might be able to extend Embperl's SSI syntax to do what the mod_include hack does. This means that can parse the directive, let OAS do its thing, and at the same time have direct access to the request object... But then, I know squat about OAS and what it does, so this may not be all that feasible :-)
Re: Another way to perhaps do this......
Wim Steven, Wouldn't it be better to subclass Apache::SSI instead of HTML::Embperl::Syntax::SSI ? That part of it would be really easy - the hard part would be actually implementing the OAS directive actions. Wim Kerkhoff [EMAIL PROTECTED] wrote: Steven Boger wrote: I've been netsearching for hours. It's time to beg for help... My apache has a hacked mod_include that has a new directive, OAS: !--OAS SETUP=www.realmedia.com/Samples/lx.shtml@TopLeft,TopRight,BottomLeft, BottomRight-- !--OAS AD=BottomRight-- Can I somehow run those directives right from mod_perl Well... Since I've been spending several hours looking at the HTML::Embperl::Syntax::SSI module (Embperl.v2), I'm going to suggest that you might be able to extend Embperl's SSI syntax to do what the mod_include hack does. This means that can parse the directive, let OAS do its thing, and at the same time have direct access to the request object... But then, I know squat about OAS and what it does, so this may not be all that feasible :-) Wim
Re: Another way to perhaps do this......
Steven Boger [EMAIL PROTECTED] said something to this effect on 09/28/2001:
I've been netsearching for hours. It's time to beg for help...
My apache has a hacked mod_include that has a new directive, OAS:
!--OAS
SETUP=www.realmedia.com/Samples/lx.shtml@TopLeft,TopRight,BottomLeft,
BottomRight--
!--OAS AD=BottomRight--
Can I somehow run those directives right from mod_perl
After this tag is parsed, there are a number of variables in %ENV
that you can access, named based on the positions you specify in
the setup up. In the case of the above example, the variables
are OAS_TopLeft, OAS_TopRight, OAS_BottomLeft, and
OAS_BottomRight.
You can get them from the subprocess_env table:
my $top_left = $r-subprocess_env('OAS_TopLeft');
my $top_right= $r-subprocess_env('OAS_TopRight');
my $bottom_left = $r-subprocess_env('OAS_BottomLeft');
my $bottom_right = $r-subprocess_env('OAS_BottomRight');
...assuming that the setup tag has been parsed. You can also get
them via SSI #echo statements:
!--#echo var=OAS_TopLeft encoding=none --
My experience has been that OpenAdStream does a lot of things
well, but interacting with mod_perl is not one of them. We were
hitting this wall a efw months ago, and were unable to come up
with a decent, well-integrated, programmatic solution. We have
come up with a replacement for all this madness using the JX
method and a dedicated module that write the JavaScript, which is
really ugly but surprisingly effective. It doesn't require that
the perl module hit the OAS server or call any oas methods.
Email me offlist if you are interested in hearing how we did it.
(darren)
--
I interpret advertising as damage and route around it.
Re: Another way to perhaps do this......
Steven Boger wrote: I've been netsearching for hours. It's time to beg for help... My apache has a hacked mod_include that has a new directive, OAS: !--OAS SETUP=www.realmedia.com/Samples/lx.shtml@TopLeft,TopRight,BottomLeft, BottomRight-- !--OAS AD=BottomRight-- Can I somehow run those directives right from mod_perl Well... Since I've been spending several hours looking at the HTML::Embperl::Syntax::SSI module (Embperl.v2), I'm going to suggest that you might be able to extend Embperl's SSI syntax to do what the mod_include hack does. This means that can parse the directive, let OAS do its thing, and at the same time have direct access to the request object... But then, I know squat about OAS and what it does, so this may not be all that feasible :-) Wim
