I'd like to propose a change to how the LzHTTPLoader API work. (This
is not a requirement for XMLRPC but something that I have wanted to do
for awhile).
Currently, LzHTTPLoader is responsible for both fetching remote data,
and parsing it into a
platform-independent LFC DOM tree.
I'd like to make it so that LzHTTPLoader is just responsible for
loading raw text data, and moving the
responsibility to parse that into LFC DOM XML up one level, to the caller.
There are already utility kernel APIs, LzXMLParser, and LzXMLTranslator,
which assist this operation, they are current being called inside of
LzHTTPLoader:
+ LzXMLParser calls the native platform XML parser on a text string
+ LzXMLTranslator copies a native platform XML tree into a tree of
LFC DOM objects.
I'd like to propose that we hoist the calls to LzXMLParser and
LzXMLTranslator out of
LzHTTPLoader, so that you have the option of not trying to interpret
the results as XML.
In this proposal, the caller of LzHTTPLoader would now be responsible
for explicitly making the calls to LzXMLParser
and LzXMLTranslator, if they wanted to parse the data.
There is only one caller of LzHTTPLoader right now,
LzHTTPDataProvider, so making this change
shouldn't impact anyone, except external developers who are using the
LzHTTPLoader API
directly now, and it's not an external API, so they shouldn't feel too put out.
The RPC library uses loaders also, but I'm tearing that stuff up now
anyway, so modifying the caller there
this is the least of my worries.
There have been at least one or two user community requests to be able
to load raw text data without
having the loader try to parse it as XML.
N.B., In DHTML, the native XMLHTTPRequest call does in fact attempt to
parse the response text as XML unconditionally, but in that case we'll
just set a property pointing to the native
parsed XML, and the caller can then elect not to reparse the raw data
if it is already there.
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
