[...]
> I have two problems with that interpretation:
>
> 1) If the spec means this, then the reference to HTTP is entirely
> superfluous, because ANY data can be the body of an HTTP POST request, and
> HTTP does not assign any meaning to the bytes in the body.
>
> 2) While I like your definition of message as being just data, it's
> common in computer specs to use "message" to mean not only the data,
> but the event of the data being transmitted.
It is indeed a very frequent misuse, which may mean that some day the
dictionary meaning of message may change from just data to the transmision
sequence in which data are carried. Maybe we'll even be alive to see it.
> In RFC 2616 (HTTP),
> there's a little confusion as to which it means by "message," but in
> the terminology section, it goes out of its way to say that it's only
> a message if it's transmitted over the connection, which I believe
> really means that the transmission itself is the message. It says a
> "request" is a kind of message.
>
> Even if you look at all this as just specifying sequences of bytes and
> not events relating to them, an HTTP POST request, in the language of
> RFC 2616, includes all the HTTP headers, and therefore if an XML-RPC
> message is an HTTP POST request (as the XML-RPC spec says), then HTTP
> is not optional.
I'll have to respectfully disagree on this: headers are part of the set of
bytes presented by the HTTP service, so they are part of the message (they
would be considered as its envelope in OSI parlance), and the XML-RPC
"message" can therefore be provided by any sublayer exposing data according
to the HTTP external behaviour for POST requests, not requiring that HTTP -
as a protocol - be used; only that any substitution sublayer expose the same
results to the XML-RPC layer.
>
> >Think: "I'll have a glass of water";
>
> I read it more as, "I'll have mineral water", which means you'll have
> a certain kind of water, not that you'll have the kind of minerals
> that come in mineral water. An XML-RPC message is a certain kind of
> HTTP POST request.
Make that "the set of bytes" transported in a HTTP request, and I'll have no
problem with that. Not that I actually have a problem with your
interpretation: it just seems to be more restrictive that mine, meaning your
code will be "conservative in what you put out", as suggested by the short
form of Postel's law (which apparently has already been used several times
in XML-RPC discussions), which is a good thing.
> Concerning gateways and proxies and protocol converters: If you have
> to use a gateway to get Client C to talk to Server S, I don't think
> you can say that C and S both speak XML-RPC. The XML-RPC compliant
> client in this case would see the combination of S and the gateway as
> its XML-RPC server.
Your interpretation is certainly correct: technically, the actual XML-RPC
server is made up of the gateway + the "nonstandard" server. OTOH, if the
gateway is implemented as a transparent proxy, the client still addresses
the "nonstandard" server and the gateway works its magic.
> >Dave Winer (who ultimately is probably the only authority on XML-RPC)
> Dave's not the authority.
I must have missed a step here. He is apparently the author of the spec, and
Userland appears to own a copyright on it (as per
http://www.xmlrpc.org/spec), as well as the XML-RPC trademark.
You seem to think otherwise and, since no one appears to contradict your
point of view, I suppose it can be upheld as correct, but this is strange to
me.
> He's only the authority on his original
> intentions, which don't count for much.
???
> The spec stands on its own
> there, and we all just have to do our best to read it like our
> colleagues are reading it, so that our clients and servers work
> together.
Amen to that.
I think we've been over the differences in our interpretations, don't you ?
Frederic
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/xml-rpc/
<*> To unsubscribe from this group, send an email to:
xml-rpc-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|
