On Jan 20, 2004, at 2:25 PM, Mario Salzer wrote:
... (But then for implementors, this was just a simple string replacing effort afterwards).
I hope I'm misunderstanding you...
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.
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.
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.
