> On Jan 20, 2004, at 15:31, Ken Gengler wrote: > > Part of the reason I wanted to use XML-RPC was that it was fairly > efficient. Have the server run a "simple string replacing" effort on > the output of an XML parser? The performance hit on any sizable > document is going to be major. It means the server must keep the entire > output string in memory and then *duplicate* it (and to avoid altering > any <string/>'s that might appear in the strings themselves, you'll > have to do the scan/replace of <, >, and & characters in memory first). > This is also true for your restriction against CDATA. Again, each > string must be in memory and scanned for <, >, and &. Any chance of > allowing a string to be generated straight to the output stream is gone > - you have to walk each string, character by character to the output > stream.
The reason for all those restrictions was to allow for XML-RPC that is a lot faster than current implementations, just by leaving out the XML parser at all. But I see your point, and I think it would lead only to a little slowdown to allow <![CDATA[ sections then. But I'm still wondering if this didn't only change the escape sequence from "<" and "&" to "]]" - which btw, ends up in a more difficult string walking. Whatever, I think it would be little disturbtion for token parsers to get CDATA right, but personally I'd like to then allow this only for <string> tags (this was also a requirement in Adam Megacz` earlier "XMC" RFC, but that he tried to introduce an <unicode> tag). So now was it possible with your XML lib to only put strings out into CDATA sections, but NOT using this for <int> or <boolean>? (if you supplied a DTD telling your XML toolkit so) But the <emptytag/> problem makes me really worry, because it was a really huge slowdown for token parsers to scan for #<emptytag\s*/># then. Isn't is possible with newer toolkits to instruct them to write the tags in canonicalized form in the first place? > Since I'm often sending a 200k+ string via XML-RPC, I was able to get a > 5X performance improvement by simply using CDATA and allowing JDOM to > stream directly to the output stream. The result was perfectly > acceptable to any XML parser. I'd hate to lose the performance for the > sake of a few languages that can't manage proper XML parsing (esp since > I'm not talking to those languages anyway). In fact, I'd probably have > to look elsewhere as XML-RPC would become such a performance pig. There wouldn't likely be any change, if it was ensured that you always talked to a XML parser enabled client or server. The draft I presented almost everywhere uses "MUST", but this won't limit implementors using it in totally weird ways, just because of the simple fact, that RPC is just program glue and client and server already agreed on method name, parameters and then how exactly to transmit it. That draft is of course meant to get near a standard, but I don't see any chance that everybody would actually negotiate on this. > If XML-RPC only serves the needs of the least common denominator, it > will be relegated to small, lightly trafficked services. Any serious > enterprise will not be able to consider it due to the server resource > requirements and its inefficiencies. I know that I must live with in my > java server's limits. These XML limits would be a really drain of my > limited resources. The light web services was my understanding of XML-RPC. It was an initial design goal to keep things as simple as possible. However as I liked to point out, it was not my intend to push any limitations that would break compatibility - I'm well aware, that most implementations use a real XML parser, but anyhow there are a lot that don't. And now the whole point is to get the best match to support the slow XML parsers and the simple token parsers. So, thanks for your note; I'm more enlightened now. mario
