httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [PROPOSAL] xml-related changes to apreq2
Date Thu, 01 Apr 2004 17:58:15 GMT
Joe Schaefer wrote:
> Stas Bekman <stas@stason.org> writes:
> 
> 
>>Joe Schaefer wrote:
> 
> 
> [...]
> 
> 
>>>In so doing I've replaced the req->body table with new hooks in the
>>>parser.  The hooks will provide a simple iterator api together with
>>>a means of converting the iterated-over elts into apreq_param_t's.
>>>This additional level of indirection will allow us to continue support
>>>for the current apreq_param(s)-related APIs by using the iterator
>>>api internally (instead of searching the old req->body table). 
>>
>>
>>What's the performance hit added by this transition? I'd hate to see
>>the library slow down, just because it suddenly wants to parse xml.
> 
> 
> I can't say for certain, since I haven't implemented it yet.
> However, I expect it to be something like this:
> 
>   1) existing parsers will not be negatively impacted, since they will 
>      just relocate the req->body table to ctx->body. Future (xml)
>      parsers will see a large benefit though, because they can use 
>      whatever data type they want for storing their parsed data.
> 
>   2) The current accessor apis (apreq_param, apreq_params, apreq_upload,
>      apreq_uploads) will take a performance hit due to the additional 
>      indirection: they'll need to call req->parser->it_init() to get an 
>      iterator, and then call req->parser->it_next() to get the result.  
>      This is additional overhead when compared to a direct call to 
>      apr_table_get(req->body, key), but I don't know how significant
>      the extra overhead will be.

So once modified you will never know what was the impact. Perhaps we need to 
benchmark the two implementations (once you have it changed) and see how bad 
it is and whether it's worth it.

> However, it has always been an express goal of apreq2 to provide support
> for xml parsers, especially wrt XForms.  Without such a change, I don't 
> think that XForms will happen in apreq2, since apr_tables are simply the 
> wrong data structure for representing xml docs.

Why again apreq2 is supposed to support xml? You never really explained the 
reason for that goal. I wasn't aware there was such a goal.

__________________________________________________________________
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

Mime
View raw message