You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Stas Bekman <st...@stason.org> on 2003/05/01 02:05:14 UTC
Re: [apreq-2 proposal] backporting apreq_tables to APR
Joe Schaefer wrote:
> I've been thinking about ways to cut down on the
> size of the libapreq-2 library, and it looks to
> me like there's a way to backport the apreq table
> implementation cleanly into apr_tables. Basically
> all that needs to be done is to adjust the
> table_entry's pointer from v to v->data and expose
> the struct in the header. Of course, the APR
> guys may say no, but in this case the time wasted
> would be substantially less than last year's attempt
> to include libapreq-2 into the httpd dist.
>
> Thoughts?
Ask apr-dev and let's see what they have to say, before wasting any time at
all. Or do you think that if a patch is sent instead of an rfc it'll be more
instrumental in making the the decision in favor of this move?
Assuming that they welcome this change and the next Apache version will
include it. This will mean that apreq will be available on with that version
or higher. Is that OK?
__________________________________________________________________
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
Re: [apreq-2 proposal] backporting apreq_tables to APR
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>You mean apreq returning APREQ::Table objects to the perl land and
>>perl manipulating these directly, just like we do with APR::Table
>>objects ($r->headers_in, etc). Correct?
>
>
> Right.
>
>
>>If apr won't accept your implementation than we can still have
>>Apache::Request for the normal functionality, and APREQ::Table or
>>Apreq::Table for your tables implementation. Also while you are at it,
>>can you give an example of when do you return APREQ::Table objects?
>
>
> my $apreq = Apache::Request->new($r;
> my $jar = Apache::Cookie->new($r);
> ...parse request...
>
> # potential APREQ::Table objects
> my $args = $apreq->args;
> my $body = $apreq->body;
> my $params = $apreq->params; # args + body
> my $cookies = $jar->cookies;
Looks great to me. It'll either become APR::Table or it'll be APREQ::Table if
not accepted by apr-dev. I'd still fight for having something better than
APREQ:: if the latter happens (which is quite possible). Otherwise, I don't
see any problem with having Apache::{Request|Cookie} and ApGodKnowsWhat::Table
live together. Just like Apache::RequestRec returns APR::Table objects in mp2.
__________________________________________________________________
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
Re: [apreq-2 proposal] backporting apreq_tables to APR
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> You mean apreq returning APREQ::Table objects to the perl land and
> perl manipulating these directly, just like we do with APR::Table
> objects ($r->headers_in, etc). Correct?
Right.
> If apr won't accept your implementation than we can still have
> Apache::Request for the normal functionality, and APREQ::Table or
> Apreq::Table for your tables implementation. Also while you are at it,
> can you give an example of when do you return APREQ::Table objects?
my $apreq = Apache::Request->new($r;
my $jar = Apache::Cookie->new($r);
...parse request...
# potential APREQ::Table objects
my $args = $apreq->args;
my $body = $apreq->body;
my $params = $apreq->params; # args + body
my $cookies = $jar->cookies;
--
Joe Schaefer
Re: [apreq-2 proposal] backporting apreq_tables to APR
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
>>>>Assuming that they welcome this change and the next Apache version
>>>>will include it. This will mean that apreq will be available on with
>>>>that version or higher. Is that OK?
>>>
>>>Works for me- and means we can keep the perl API contained within
>>>the Apache::Request / Apache::Cookie namespace.
>>
>>Sorry, I'm not following you on the last note regarding the perl API.
>>
>
>
> Basically, apreq_tables accounts for ~ 30% of libapreq-2.so and
> would probably would need a Perl API. Finding a suitable namespace
> for it is a royal PITA, which is why I suggested /^APREQ::/i.
> OTOH, if the functionality gets folded into APR, this problem
> seems to disappear, as does the need for /^APREQ::/i.
You mean apreq returning APREQ::Table objects to the perl land and perl
manipulating these directly, just like we do with APR::Table objects
($r->headers_in, etc). Correct?
If apr won't accept your implementation than we can still have Apache::Request
for the normal functionality, and APREQ::Table or Apreq::Table for your tables
implementation. Also while you are at it, can you give an example of when do
you return APREQ::Table objects?
__________________________________________________________________
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
Re: [apreq-2 proposal] backporting apreq_tables to APR
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
> > Stas Bekman <st...@stason.org> writes:
> > [...]
> >
> >>Ask apr-dev and let's see what they have to say, before wasting any
> >>time at all. Or do you think that if a patch is sent instead of an
> >>rfc it'll be more instrumental in making the the decision in favor
> >>of this move? Making the necessary changes didn't take much time at
> >>all (apr patch below).
>
> Wow, that was quick! Go ahead and send it to apr-dev then.
Done.
> >>Assuming that they welcome this change and the next Apache version
> >>will include it. This will mean that apreq will be available on with
> >>that version or higher. Is that OK?
> > Works for me- and means we can keep the perl API contained within
> > the Apache::Request / Apache::Cookie namespace.
>
> Sorry, I'm not following you on the last note regarding the perl API.
>
Basically, apreq_tables accounts for ~ 30% of libapreq-2.so and
would probably would need a Perl API. Finding a suitable namespace
for it is a royal PITA, which is why I suggested /^APREQ::/i.
OTOH, if the functionality gets folded into APR, this problem
seems to disappear, as does the need for /^APREQ::/i.
--
Joe Schaefer
Re: [apreq-2 proposal] backporting apreq_tables to APR
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
> [...]
>
>
>>Ask apr-dev and let's see what they have to say, before wasting any time at
>>all. Or do you think that if a patch is sent instead of an rfc it'll be more
>>instrumental in making the the decision in favor of this move?
>
>
> Making the necessary changes didn't take much time at all (apr patch below).
Wow, that was quick! Go ahead and send it to apr-dev then.
>>Assuming that they welcome this change and the next Apache version will include
>>it. This will mean that apreq will be available on with that version or
>>higher. Is that OK?
>
>
> Works for me- and means we can keep the perl API contained within
> the Apache::Request / Apache::Cookie namespace.
Sorry, I'm not following you on the last note regarding the perl API.
__________________________________________________________________
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
Re: [apreq-2 proposal] backporting apreq_tables to APR
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Ask apr-dev and let's see what they have to say, before wasting any time at
> all. Or do you think that if a patch is sent instead of an rfc it'll be more
> instrumental in making the the decision in favor of this move?
Making the necessary changes didn't take much time at all (apr patch below).
> Assuming that they welcome this change and the next Apache version will include
> it. This will mean that apreq will be available on with that version or
> higher. Is that OK?
Works for me- and means we can keep the perl API contained within
the Apache::Request / Apache::Cookie namespace.