-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 25, 2001 8:55 AM
To: 'Doug MacEachern'; Stas Bekman
Cc: modperl-2.0 dev-list
Subject: RE: Apache2:: namespace, prerequisite checking and
CPAN listing
oh, I forgot to mention that I know we can
Hi Doug,
for my implemetation of the interface to mod_dav I again looked thru your
code that generates the XS for mod_perl 2.0. I have done this the first time
when I implemented my HTTP::Webdav (which is a webdav client and will be
soon on CPAN). For this first project that does automaticly
-Original Message-
From: Ken Williams [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 25, 2001 11:06 AM
To: Geoffrey Young
Cc: modperl-2.0 dev-list
Subject: RE: Apache2:: namespace, prerequisite checking and
CPAN listing
[snip]
It should be sufficient to do:
use mod_perl;
On Fri, 25 May 2001, Geoffrey Young wrote:
-Original Message-
From: Ken Williams [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 25, 2001 11:06 AM
To: Geoffrey Young
Cc: modperl-2.0 dev-list
Subject: RE: Apache2:: namespace, prerequisite checking and
CPAN listing
[snip]
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 25, 2001 11:26 AM
To: Geoffrey Young
Cc: 'Ken Williams'; modperl-2.0 dev-list
Subject: RE: Apache2:: namespace, prerequisite checking and
CPAN listing
[snip]
use mod_perl 2;
use mod_perl 1;
On Fri, 25 May 2001, Ken Williams wrote:
[EMAIL PROTECTED] (Stas Bekman) wrote:
It should be sufficient to do:
use mod_perl;
BEGIN { die horribly if $mod_perl::VERSION = 2 }
It's very handy to remember that 'use' is just 'require' and
'import' in a 'BEGIN' block.
I
On Thu, May 24, 2001 at 05:52:39PM -0700, Doug MacEachern wrote:
let's consider everything before adding new code.
Ok :-). I have a reply in queue that works through your ideation w/
questions suggestions. But first, let's look at really bifurcating
the API into a Perl*Filter API and a more
i intended to make the mod_perl-2.0 code generation tied tight to
Apache/mod_perl. i didn't want to build a generic tool, like another swig
or Inline.pm, i only wanted something generic enough to work with the
entire Apache/APR api, along with Apache modules like mod_dav, mod_proxy,
etc. my
Background: A couple of yuears ago I wrote a complete Perl input/output
filtering system much like the current Apache filter system and a bunch
of filters for it. I'm hoping to port it to mod_perl-2.0 and let
mod_perl do the heavy lifting (filters are just a pain to manage).
Having done a bunch
what should 'no mod_perl 2.0' todo?
die if $mod_perl::VERSION = 2.0 ?
just something like
$ perl -e no mod_perl 2.0
mod_perl version 2.0 too high--this is version 1.2501 at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
was all I had in mind...
--Geoff
On Fri, 25 May 2001, barries wrote:
On Thu, May 24, 2001 at 05:52:39PM -0700, Doug MacEachern wrote:
let's consider everything before adding new code.
Ok :-). I have a reply in queue that works through your ideation w/
questions suggestions. But first, let's look at really bifurcating
On Fri, 25 May 2001, barries wrote:
Adding a Apache::Filter::send_EOS() would also allow a filter to purge
APR::{Brigade,Bucket} apis already provide this. i don't want to add
methods to Apache::Filter that exist elsewhere.
Wow, that's a lot of blather. Sorry.
that is a alot to digest,
On Fri, May 25, 2001 at 11:37:01AM -0700, Doug MacEachern wrote:
i think we should focus on getting the rest of the direct C api
mapping done, which we want in any case. with that in place, you
should be able to prototype the approach you outlined here as a pure
Perl module.
Yeah, I
On Fri, 25 May 2001, barries wrote:
I think that two things are necessary to enable a pure Perl
implementation:
- adding is_BOS() and is_EOS() to Apache::Filter (or to
Apache::{Brigade,Bucket}, and
if you really need to know bos (beginning of string?) and eos, you can use
the
On Fri, 25 May 2001, barries wrote:
Ok, I think I was underestimating how much padding you wanted on the
direct C API mapping. I thought that that would be 0 padding (like how
the ctx param to $r-add_output_filter() is treated).
i would like 0 padding for the 'direct' mapping. the padding
On Fri, 25 May 2001, Gerald Richter wrote:
ok, I give it a try. I don't expect it to be a real general tool (I think I
don't have the time to really abstract all the work you have done in a more
general way), but something that I can use to build the mod_dav backend for
mod_perl 1.x and
On Fri, May 25, 2001 at 02:31:38PM -0700, Doug MacEachern wrote:
On Fri, 25 May 2001, barries wrote:
I think that two things are necessary to enable a pure Perl
implementation:
- adding is_BOS() and is_EOS() to Apache::Filter (or to
Apache::{Brigade,Bucket}, and
if you
On Fri, 25 May 2001, barries wrote:
BOS=Beginning Of Stream, like EOS=End Of Stream (I assume)
right, stream, not string.
I didn't see any flags in the filter, filter chain, bucket brigade or
bucket structures/APIs that indicate that this is the first brigade.
Normally I think stateful
On Fri, May 25, 2001 at 03:52:31PM -0700, Doug MacEachern wrote:
On Fri, 25 May 2001, barries wrote:
We're on the same page, but right now $ctx in the $r-add_xxx_filter(
foo, $ctx) is written to the f-ctx field that the modperl_filter_t
comes to reside in. So I'm proposing a perl_ctx
On Fri, 25 May 2001, barries wrote:
Apache::ap_add_output_filter( foo, AP_FTYPE_CONTENT, $ctx )
you mean ${r,c}-add_output_filter(foo, $ctx), right?
where Foo is not related to mod_perl, you better be passing an integer
in $ctx which is a pointer to some C struct you cooked up in XS
On Fri, May 25, 2001 at 06:30:03PM -0700, Doug MacEachern wrote:
On Fri, 25 May 2001, barries wrote:
Apache::ap_add_output_filter( foo, AP_FTYPE_CONTENT, $ctx )
you mean ${r,c}-add_output_filter(foo, $ctx), right?
Yeah. Getting late...
where Foo is not related to mod_perl, you
21 matches
Mail list logo
