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 2004/10/05 05:39:00 UTC
$bucket->setaside($pool);
setaside API needs to be changed as it strays from the rest of the API.
Since all it can return is errors which are useless to trap it shouldn't
return anything. It should run MP_RUN_CROAK like other methods do. It's
still possible to trap those with APR::Error, but who will.
Joe, please let me know if you want to do that, or I can handle that.
--
__________________________________________________________________
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: $bucket->setaside($pool);
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> So as we discussed I'll change the code to croak in the void context
> and return the status otherwise.
Cool- thanks Stas!
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $bucket->setaside($pool);
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>Joe Schaefer wrote:
>>
>>>Stas Bekman <st...@stason.org> writes:
>>>
>>>
>>>>setaside API needs to be changed as it strays from the rest of the
>>>>API. Since all it can return is errors which are useless to trap it
>>>>shouldn't return anything. It should run MP_RUN_CROAK like other
>>>>methods do. It's still possible to trap those with APR::Error, but who
>>>>will.
>>>
>>>You should allow users to check for APR_ENOTIMPL, because
>>
>>But your implementation of modperl_bucket_sv_setaside doesn't ever return
>>it. I'm not following you, Joe.
>
>
> apr_bucket_setaside is exposed for *any* type of bucket now, not just
> mod_perl buckets. Invoking it on other bucket types (like pipe and
> socket buckets currently) will return APR_ENOTIMPL.
>
>
>
>>>they might be able to handle that case the same way ap_save_brigade does.
>>>So I agree that it should throw an exception in void context, but
>>>would prefer if it didn't do that in scalar/list context.
>>
>>I don't think it makes sense in the particular case of mod_perl. The
>>only users of modperl buckets are modperl users, and setaside is now
>>implemented. So why
>>would users want to check any success codes explicitly?
>
>
> Someone writing a filter with mod_perl may need to setaside certain
> buckets which the filter did not itself create (ie those coming from the
> content handler in the output filter case, or those coming from mod_ssl
> in the input filter case).
Yes, of course, I've completely missed that :) Thanks Joe.
So as we discussed I'll change the code to croak in the void context and
return the status otherwise.
--
__________________________________________________________________
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: $bucket->setaside($pool);
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> >
> >>setaside API needs to be changed as it strays from the rest of the
> >>API. Since all it can return is errors which are useless to trap it
> >>shouldn't return anything. It should run MP_RUN_CROAK like other
> >>methods do. It's still possible to trap those with APR::Error, but who
> >> will.
> > You should allow users to check for APR_ENOTIMPL, because
>
> But your implementation of modperl_bucket_sv_setaside doesn't ever return
> it. I'm not following you, Joe.
apr_bucket_setaside is exposed for *any* type of bucket now, not just
mod_perl buckets. Invoking it on other bucket types (like pipe and
socket buckets currently) will return APR_ENOTIMPL.
> > they might be able to handle that case the same way ap_save_brigade does.
> > So I agree that it should throw an exception in void context, but
> > would prefer if it didn't do that in scalar/list context.
>
> I don't think it makes sense in the particular case of mod_perl. The
> only users of modperl buckets are modperl users, and setaside is now
> implemented. So why
> would users want to check any success codes explicitly?
Someone writing a filter with mod_perl may need to setaside certain
buckets which the filter did not itself create (ie those coming from the
content handler in the output filter case, or those coming from mod_ssl
in the input filter case).
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: $bucket->setaside($pool);
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>setaside API needs to be changed as it strays from the rest of the
>>API. Since all it can return is errors which are useless to trap it
>>shouldn't return anything. It should run MP_RUN_CROAK like other
>>methods do. It's still possible to trap those with APR::Error, but who
>>will.
>
>
> You should allow users to check for APR_ENOTIMPL, because
But your implementation of modperl_bucket_sv_setaside doesn't ever return
it. I'm not following you, Joe.
> they might be able to handle that case the same way ap_save_brigade does.
> So I agree that it should throw an exception in void context, but
> would prefer if it didn't do that in scalar/list context.
I don't think it makes sense in the particular case of mod_perl. The only
users of modperl buckets are modperl users, and setaside is now
implemented. So why would users want to check any success codes explicitly?
>>Joe, please let me know if you want to do that, or I can handle that.
>
>
> Please fix it for me Stas- thanks!
Sure, once we figure out what exactly needs to be done.
--
__________________________________________________________________
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: $bucket->setaside($pool);
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> setaside API needs to be changed as it strays from the rest of the
> API. Since all it can return is errors which are useless to trap it
> shouldn't return anything. It should run MP_RUN_CROAK like other
> methods do. It's still possible to trap those with APR::Error, but who
> will.
You should allow users to check for APR_ENOTIMPL, because
they might be able to handle that case the same way ap_save_brigade does.
So I agree that it should throw an exception in void context, but
would prefer if it didn't do that in scalar/list context.
> Joe, please let me know if you want to do that, or I can handle that.
Please fix it for me Stas- thanks!
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org