DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16658>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16658 replace (depricate) output_value with a reflection of store [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 2003-06-04 10:36 ------- The apr_xml_* structures are used for parsing, rather than as a generic DOM mechanism. mod_dav would simply serialize the result anyways. The output_value function was designed to move the serialization into the provider. This was done because the provider knows *much* more about how to efficiently serialize the results. In fact, it could be very painful for the provider to construct an apr_xml_elem structure simply to see mod_dav serialize it for output. As an example, mod_dav_fs pre-serializes all properties. When you do a PROPFIND, it just yanks them out of the DB and returns them. That's why we do all the funky namespace mapping backflips. In a future revision of the API, we'll even eliminate the text stuff, and ask the provider to jam the results directly into an Apache output filter (much like how the reports operate). Then we can see some *real* kickass stuff since writing values into a filter can use zero-copy techniques for high efficiency. Imagine doing an array-fetch from Oracle, and referring to the output binding buffers with some TRANSIENT buckets, and tossing those into the filter. I'm closing this enhancement request as WONTFIX. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
