On Fri, 2003-01-31 at 12:34, Stas Bekman wrote:
> In mod_perl 1.0 Apache->request was always there. In 2.0 it's there only if
> it's configured to be there('PerlOptions +GlobalRequest' or 'SetHandler
> perl-script'). I believe that if I write a module that relies on
> Apache->request, I shouldn'
Philippe M. Chiasson wrote:
On Fri, 2003-01-31 at 07:01, Stas Bekman wrote:
Doug, have you intended ModPerl::MM to be used only internally to the mod_perl
build or by other 3rd party modules as well?
I like it much more than Apache::src. I'm currently porting Apache::Peek and
the Makefile.PL
Philippe M. Chiasson wrote:
On Thu, 2003-01-30 at 12:32, Stas Bekman wrote:
The attached patch (because it has \t embedded) enables the installation of
src/modules/perl/*.h and xs/*.h files, because we need them to be installed
for XS extensions to be built.
+1 Great!
First of all I'm not
On Fri, 2003-01-31 at 07:01, Stas Bekman wrote:
> Doug, have you intended ModPerl::MM to be used only internally to the mod_perl
> build or by other 3rd party modules as well?
>
> I like it much more than Apache::src. I'm currently porting Apache::Peek and
> the Makefile.PL is:
>
> use Apache2;
On Thu, 2003-01-30 at 12:32, Stas Bekman wrote:
> The attached patch (because it has \t embedded) enables the installation of
> src/modules/perl/*.h and xs/*.h files, because we need them to be installed
> for XS extensions to be built.
+1 Great!
> First of all I'm not sure if that's the right
In mod_perl 1.0 Apache->request was always there. In 2.0 it's there only if
it's configured to be there('PerlOptions +GlobalRequest' or 'SetHandler
perl-script'). I believe that if I write a module that relies on
Apache->request, I shouldn't test whether Apache->request has returned
something o
As I was exposing mpxs_Apache_request as I needed it in Apache::Peek, I was
thinking what is the public C mod_perl API. Is that everything that is defined
in mod_?perl.*\.h and modperl_xs.*\.h files? What about the XS extensions, if
a 3rd party app wants to use a C function which is not in the c
Doug, have you intended ModPerl::MM to be used only internally to the mod_perl
build or by other 3rd party modules as well?
I like it much more than Apache::src. I'm currently porting Apache::Peek and
the Makefile.PL is:
use Apache2;
use mod_perl 1.99;
use ModPerl::MM ();
ModPerl::MM::WriteMak
Matt Sergeant <[EMAIL PROTECTED]> writes:
> On Thursday, Jan 30, 2003, at 15:24 Europe/London, Thomas Eibner wrote:
[...]
> > Are they being responsive or?
>
> No, I don't even think it got past non-subscriber moderation. However
> my original patch was naive, and didn't account for continuati
On Thursday, Jan 30, 2003, at 15:24 Europe/London, Thomas Eibner wrote:
What I was thinking was just that since you can add a header with
$r->headers_out->add it would be possible to add something there to
remove newlines, but since it's probably just an Apache::Table
operation
it wouldn't "know
Thomas Eibner wrote:
From: Service FC <[EMAIL PROTECTED]>
Reply-To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Removed From APX Listings
X-Mailer: Version 5.0
MIME-Version: 1.0
Didn't we have a problem with them on the other list at one point?
I get a 'you have been removed' email from
From: Service FC <[EMAIL PROTECTED]>
Reply-To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: Removed From APX Listings
X-Mailer: Version 5.0
MIME-Version: 1.0
Didn't we have a problem with them on the other list at one point?
--
On Thu, Jan 30, 2003 at 02:36:53PM +, Matt Sergeant wrote:
> > And I don't really think it's designed to output a header. Tables where
> > used because it made it easy to implement (I assume), and it's only in
> > mod_perl and not the C api that there are specific functions for adding
> > to r
On Tue, 28 Jan 2003, Thomas Eibner wrote:
> Yes, that sounds very weak. To me it sounds like Matt doesn't know what
> he is doing if he's passing RAW input from a client directly into
> something. I know it sounds harsh and I'm not trying to degrade Matt as
> I have great respect for the work he i
14 matches
Mail list logo