This all sounds like it adds a lot of complexity in order to extend the reach of XML-RPC. For me, the main problems with the spec as defined is the coupling with HTTP 1.0 and the lack of support for nulls. I'd like to see this in an RFC, but I think reaching out to lexers instead of focusing on XML parsers adds unnecessary complexity. IOW, I'd like to see any RFC build on the XML spec instead of trying to cherry pick stuff from it. I have no problem ignoring namespaces; anyway, thats in a different w3c recommendation.
For the types of devices that really need the resources savings that removing the entire XML parser would provide, why not look into a simpler TCP or HTTP based RPC?
-- Ryan Hoegg ISIS Networks http://www.isisnetworks.net
Ken Gengler wrote:
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
