On Jan 20, 2004, at 4:58 PM, Mario Salzer wrote:
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.
True, although the <![CDATA[ sequence is only really likely to be seen in cases where your sending an XML document within the XML-RPC document. I'm more comfortable putting a restriction on such embedded documents than I am on the XML-RPC document. The reason is that I building an XML DOM explicitly and, thus, I'd have to add a CDATA node explicitly to have one in the output. Thus, I can explicitly avoid it - and I can easily comply with the restriction. I don't know if that would be universally acceptable.
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)
Allowing them only in string tags seem reasonable. Again, I'm using them to avoid the encoding hit over large strings. ints or booleans should never be more than a few characters.
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?
Well, i know that JDOM can be told to do so. And, if other parsers do as well, I think this is an acceptable restriction. It just worried when when I heard the statement "simple search replacing" as a requirement for the server. On any string of decent size, it can become a performance problem for a high volume service.
I'm left wondering if there couldn't be some sort of "acceptable formats" negotiation in the XML-RPC request. If the client stated that it couldn't handle empty tags or CDATA's, etc., the server could avoid using them. That way, the server could conserve resources for the majority of the clients that work with it. Perhaps this "acceptable formats" information could simply be an attribute to the methodCall tag?
Ken
---------- Ken Gengler Senior Software Engineer, TechTracker Inc [EMAIL PROTECTED], 503-227-2571 x228
