DO NOT REPLY [Bug 16658] - replace (depricate) output_value with a reflection of store

[bu...@apache.org]

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

gstein@lyra.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gstein@lyra.org
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From gstein@lyra.org  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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org