httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [PROPOSAL] xml-related changes to apreq2
Date Thu, 01 Apr 2004 14:30:53 GMT
Stas Bekman <> 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.

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.

Joe Schaefer

View raw message