Hannes Wallnöfer <[EMAIL PROTECTED]> writes:
> 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, thank you for the background and lucid description of the
current situation. I concur.
I'm not proposing changes to the server which would result in the
XML-RPC specification becoming a moving target -- nobody wants that.
What I would like is for the specification to become HTTP version
agnostic, which really has very little to do with XML-RPC itself. In
fact, the only necessary modification to allow this is the lifting of
the arbitrary requirement of a Content-Length header.
[spec pseudo-diff]
-The Content-Length must be specified and must be correct.
+Content-Length is specified as per the HTTP version supported by the
client.
Many clients (such as the Frontier and XML-RPC Perl implementations)
use external HTTP libraries which support this change seemlessly
(i.e. libwww-perl). Other clients and servers (such as our own Apache
Java implementation) do not make use of the Content-Length header at
all, and supply it only because the specification says to do so.
Thanks, Dan
