Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: domain of gcaa-apreq-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Mail-Followup-To: apreq-dev@httpd.apache.org
To: apreq-dev@httpd.apache.org
From: Joe Schaefer <joe+gmane@sunstarsys.com>
Subject: Re: Parsing error when parsing the second time
Date: Sat, 31 Mar 2007 00:42:00 -0400
Lines: 56
Message-ID: <871wj658iv.fsf@gemini.sunstarsys.com>
References: <DE87FDD4-7912-49A9-9234-F3F8B6662A47@hybridized.org>
	<87abxu5bfe.fsf@gemini.sunstarsys.com>
	<A413A622-6ADD-4397-B6FF-822ADDB28D33@hybridized.org>
	<87648i5ac8.fsf@gemini.sunstarsys.com>
	<24066CA9-1CFB-4B83-B3AD-B34A2319ACC3@hybridized.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Mail-Copies-To: never
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
Cancel-Lock: sha1:QZUlXBN5YQ69IcPspOe3/m+PATs=
Sender: news <news@sea.gmane.org>

Andy Grundman <andy@hybridized.org> writes:

> On Mar 31, 2007, at 12:02 AM, Joe Schaefer wrote:
>
>> You're wandering into largely unchartered territory
>> by using APR:: outside of mod-perl, so  I would try
>> to be conservative if possible, and follow the examples
>> in the test code. APR::Pool has a good set of tests,
>> so I'm really not sure the problem is there or somewhere
>> in apreq's xs.  It just stood out that you were using
>> a new pool for each subroutine call, which probably
>> isn't the best way to do things.
>
> OK, thanks for the advice.  I'm actually a bit surprised this is
> uncharted territory.

Well I use it, but I don't know how many other people do.

> I'm working on trying to improve the performance of Catalyst's body
> parsing. We're currently using the all-Perl HTTP::Body, and it
> actually beats APR::Request for urlencoded data.  The regexes are
> pretty simple, so this isn't too surprising.

Still pretty impressive that you can do it faster than apreq2 can.
Have you tried comparing it with apreq2's query string parser?
That one's not stream oriented, so it should be a bit faster than
our body parser.

> Where I hope it will help a lot more is multipart/form-data parsing, but I
> don't have this working yet to see.  I also want to use it to  replace some
> uses of URI::Escape which is fairly slow compared to apreq.
>
> The reason I want it to work outside of Apache is so that people running
> Catalyst is FastCGI mode

Yeah. I've been hoping for a fastcgi module for apreq2 as well.

> , or using one of the standalone Perl servers, can benefit from the
> improved performance.  I have a grand plan of building a standalone XS
> module that does a lot of what apreq does, but without all the Apache
> requirements.  URI escaping/ unescaping, header parsing, cookies,
> query strings, body data, etc.  A lot of the apreq code could be used
> in something like this I think.  The barrier to entry with apreq is
> pretty high at the moment, when compared to a standard CPAN module.

One of our grand plans is to divorce APR from mod-perl iteself,
so it can ship as a standalone set of wrappers for libapr and
libaprutil.  Another is to fold apreq2's stuff into the
various projects it interacts with.

That would significantly lower the barrier to entry for apreq,
because it wouldn't even exist as a separate distribution anymore.
It would just be part of all the other stuff.

-- 
Joe Schaefer