Here's my view on the frozen spec issue, as well as some background info for those who are relatively new to XML-RPC.
As far as I know, the primary reason for Dave wanting the spec frozen is to not have too much of his small company's manpower tied up to following a moving spec. What he wants is to have a simple interoperability protocol that he knows works, and to be able to concentrate on whatever feature his company is currently working on. This is, IMHO, not a shortcoming per se but one of the very nice things about XML-RPC which makes it an ideal tool for the "small people". It also distinguishes it from something like SOAP, which can be very time consuming to follow/understand/implement. What this means is that the spec is not frozen for some fundamental reasons, but for pragmatical ones. It also means that implementations were always judged by pragmatical criteria of interoperability. One example is the use of ASCII encoding as prescribed in the spec. Of course not even Userland's software is using pure ASCII encoding, but for example ISO-8859-1 (or Microsoft's superset thereof), so it was generally accepted (and in fact highly desirable everywhere outside the English speaking area) that implementations could use extended encodings. I think there's some hope that the current issues with HTTP/1.1 support may work out in a similar pragmatical manner. There is a lot of HTTP server and client infrastructure out there, and I think there is enough natural pressure on everybody (including Userland and ourselves) to keep up with what's out there and be as close to the HTTP spec as possible. For example, if one day Userland Frontier (or any other XML-RPC client implementation) would cease to work with a new Apache httpd (which of course implements the HTTP spec very well) there would be little use to hold up the XML-RPC spec and claim it was Apache's fault. After all, the XML-RPC spec also says XML-RPC uses HTTP POST, and the HTTP POST method is defined by the HTTP specs (and the servers and clients out there implementing it). The situation is a bit different for the things that lie completely within XML-RPC. One example is missing null support (see my previous posting). I really wanted null support (and in fact I relied on it with my own work). But making that kind of extensions on the spec will undermine the core purpose of XML-RPC (interoperability) and hurt developers. So if the frustrations with core XML-RPC capabilities gets to big, the solution is to either create a new protocol or go with one that offers more flexibility (and complexity, I guess) from the start. Hannes Stuart Roll wrote: >Well, I have no history with this project and I respect the wisdom of those >who do and have labored long and hard with it. That being said, the idea >of being tied to a spec that has been described as being both deficient and >immutable is about as anti-open as you can get (without getting entirely >proprietary). > >I see only a few options we have here: > >#1 - Be blissfully content with XML-RPC as it is now and forevermore. > >#2 - Everyone makes their own local modifications to XML-RPC to make it >work well, right, keep up with the times, etc. > >#3 - Prevail upon Dave Winer (and/or UserLand) to permit the evolution of >the spec. > >#4 - Drop the trademarked "XML-RPC" name and start a new standard with a >new name which encompasses the old standard and yet allows for growth and >development in the open source community. Imagine if Sun never updated >Java 1.0! It would have been abandoned sooner or later in favor of >something else. > >Stuart >
