You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2002/08/27 07:09:25 UTC
the rest of the is_ bucket methods?
Any reason why we don't have all the is_ bucket methods, other than eos?
I need at least is_flush().
Index: xs/maps/apr_functions.map
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/maps/apr_functions.map,v
retrieving revision 1.45
diff -u -r1.45 apr_functions.map
--- xs/maps/apr_functions.map 23 Jun 2002 22:00:03 -0000 1.45
+++ xs/maps/apr_functions.map 27 Aug 2002 05:07:11 -0000
@@ -102,7 +102,17 @@
mpxs_APR__Brigade_empty #APR_BRIGADE_EMPTY
MODULE=APR::Bucket
+ mpxs_APR__Bucket_is_metadata #APR_BUCKET_IS_METADATA
+ mpxs_APR__Bucket_is_flush #APR_BUCKET_IS_FLUSH
mpxs_APR__Bucket_is_eos #APR_BUCKET_IS_EOS
+ mpxs_APR__Bucket_is_file #APR_BUCKET_IS_FILE
+ mpxs_APR__Bucket_is_pipe #APR_BUCKET_IS_PIPE
+ mpxs_APR__Bucket_is_socket #APR_BUCKET_IS_SOCKET
+ mpxs_APR__Bucket_is_heap #APR_BUCKET_IS_HEAP
+ mpxs_APR__Bucket_is_transient #APR_BUCKET_IS_TRANSIENT
+ mpxs_APR__Bucket_is_immortal #APR_BUCKET_IS_IMMORTAL
+ mpxs_APR__Bucket_is_mmap #APR_BUCKET_IS_MMAP
+ mpxs_APR__Bucket_is_pool #APR_BUCKET_IS_POOL
mpxs_APR__Bucket_insert_after #APR_BUCKET_INSERT_AFTER
mpxs_APR__Bucket_insert_before #APR_BUCKET_INSERT_AFTER
mpxs_APR__Bucket_remove #APR_BUCKET_REMOVE
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: the rest of the is_ bucket methods?
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Wed, 28 Aug 2002, Stas Bekman wrote:
>
>
>>Though for those who want to learn bucket brigades to develop in C, it's
>>easier to first do in Perl :)
>
>
> true. and should make one appreciate the simple Perl api once its done :-)
The documentation is already taking care of showing the difference :)
Any obstacles to making this simplified API available to C developers as
well? Or something similar?
>>Are you planning to do the same for connection handlers?
>
> yes.
Great!
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: the rest of the is_ bucket methods?
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 28 Aug 2002, Stas Bekman wrote:
> Though for those who want to learn bucket brigades to develop in C, it's
> easier to first do in Perl :)
true. and should make one appreciate the simple Perl api once its done :-)
> Are you planning to do the same for connection handlers?
yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: the rest of the is_ bucket methods?
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Tue, 27 Aug 2002, Stas Bekman wrote:
>
> ...
>
>>Current "examples" in tests lose flush buckets.
>
>
> ok, feel free to add is_flush and whatever you think might be needed.
> i just hope not many of them will be needed.
ok, added is_flush()
>> > also keep in mind, filters overall are another big itch that need to
>> > be scratched.
>>
>>you mean, I'm wasting my time trying to document how filters work now,
>>since it's all going to change anyway, right?
>
>
> what i mean is internal overhaul of the $filter->{print,read} concept and
> applying the same concept to input filters. the goal, as always, is to
> provide a simple api around the C filter/bucket brigade "api", which i
> personally find absolutely horrifying. i don't expect the direct Perl
> mapping to change, i just hope nobody will need (or want) to use it once
> the simple api is overhauled/completed.
that's a good idea ;)
Though for those who want to learn bucket brigades to develop in C, it's
easier to first do in Perl :)
Are you planning to do the same for connection handlers?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: the rest of the is_ bucket methods?
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 27 Aug 2002, Stas Bekman wrote:
...
> Current "examples" in tests lose flush buckets.
ok, feel free to add is_flush and whatever you think might be needed.
i just hope not many of them will be needed.
> > also keep in mind, filters overall are another big itch that need to
> > be scratched.
>
> you mean, I'm wasting my time trying to document how filters work now,
> since it's all going to change anyway, right?
what i mean is internal overhaul of the $filter->{print,read} concept and
applying the same concept to input filters. the goal, as always, is to
provide a simple api around the C filter/bucket brigade "api", which i
personally find absolutely horrifying. i don't expect the direct Perl
mapping to change, i just hope nobody will need (or want) to use it once
the simple api is overhauled/completed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: the rest of the is_ bucket methods?
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Tue, 27 Aug 2002, Stas Bekman wrote:
>
>
>>Any reason why we don't have all the is_ bucket methods, other than eos?
>
>
> testing for eos is the only thing i've seen "normal" filters do, i.e.
> stuff outside the low-level core filters.
> are there good reasons we should have all of them?
For those that are going to write real filters, which may do different
things according to the bucket type. See below for an example of needing
is_flush.
>>I need at least is_flush().
>
>
> for? i'm not doubting we should have these methods, just would like to
> understand why we would.
>
> also keep in mind, filters overall are another big itch that need to be
> scratched.
when you write an output filter, you need to pass flush buckets as is,
here is a typical brigade transform loop:
for (my $b = $bb->first; $b; $b = $bb->next($b)) {
$b->remove;
if ($b->is_eos) {
$bb_ctx->insert_tail($b);
last;
}
elsif ($b->is_flush) {
$bb_ctx->insert_tail($b);
next;
}
else {
$b->read(my $data);
$data = do_something_with_data($data);
$b = APR::Bucket->new($data);
$bb_ctx->insert_tail($b);
}
}
Current "examples" in tests lose flush buckets.
> also keep in mind, filters overall are another big itch that need to
> be scratched.
you mean, I'm wasting my time trying to document how filters work now,
since it's all going to change anyway, right?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: the rest of the is_ bucket methods?
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 27 Aug 2002, Stas Bekman wrote:
> Any reason why we don't have all the is_ bucket methods, other than eos?
testing for eos is the only thing i've seen "normal" filters do, i.e.
stuff outside the low-level core filters.
are there good reasons we should have all of them?
> I need at least is_flush().
for? i'm not doubting we should have these methods, just would like to
understand why we would.
also keep in mind, filters overall are another big itch that need to be
scratched.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org