Ryan Hoegg wrote: > 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.
The draft I made looks like overcomplicating things in comparison to the original spec. But in fact I hoped to make it as compatible as possible with the we-leave-everything-unclear-userland-spec. Though he restrictions list looks long, it just describes what almost everybody already did, but just uses the complicated RFC lingo and ABNF syntax to describe that. However it's just a draft, so if the discussions point out that XML-RPC should only be used with XML parsers, then this is what the final RFC would somewhen tell. And if not, than that final RFC will at least RECOMMEND using a XML parser. And again, allowing token parsers should not harm existing full XML aware implementations too much (a little was ok, however ;). And if we ever get a RFC, then it would become a lot easier to revise it later, and add the <nil> tag. I personally believe this won't come, because it isn't supported by all languages (the NIL in C is a memory pointer, and in Perl/PHP we have a totally different undef/NULL value, and Java has neither?). My impression of XML-RPC was always, that it was a misdesign from the beginning. While I ABSOLUTELY MAKE NO ATTEMPTS to change it, this is what it probably would look like, if it was really a XML language: http://erfurtwiki.sourceforge.net/?id=IfXmlMinusRpcWasReallyXml > 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? XML-RPC is already the most simple RPC service available. However the draft I presented obviously tries to further simplify it, and I believe a small number of _clear_ restrictions allowed much faster implementations. mario
