httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: [PROPOSAL] xml-related changes to apreq2
Date Thu, 01 Apr 2004 20:08:39 GMT
Stas Bekman <stas@stason.org> writes:

[...]

> 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.

-0.  Either we make an effort to support xml, or we don't.  This
is a design decision about apreq2's basic functionality. I'm certain 
we can come up with an implementation that's sufficiently speedy
(ie folks using Apache::Request would never know the difference),
but if you're concerned about it now, perhaps you/someone should
run some benchmarks on Apache::Request in current cvs, comparing
it against CGI.pm as a baseline reference.

Also bear in mind that apr_tables aren't particularly fast on
large data sets, so we shouldn't try to pretend that tables are 
the cat's meow.  For example, the old apreq_tables implementation 
(in CVS) does lookups much faster and with far better scalability. 
If we dumped req->body entirely, we no longer are confronted with 
apreq2 choosing "the best data structure" for parsers to store their 
data in.  Each parser would be able to choose what's best for itself.

[...]

> 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. 

XForms etc. has been in the STATUS file since forever.  It's billed
as the replacement for HTML forms, and specificies some interoperability
between multipart/form-data, application/x-www-urlencoding and
application/xml.  Currently we're lacking a parser api suitable for 
the xml component of XForms (you really can't stuff an xml document 
into an apr_table).

-- 
Joe Schaefer


Mime
View raw message