I can give a little insight as to why being able to "break" the spec in regards to transport layer is very desirable in some situations.
I work with embedded systems and often times need a messaging or RPC style protocol. I don't know how many different times I've had to reimplement a fairly low level scheme to do RPC's from a host to a target. Now, with the advent of some embedded tcp/ip stacks and some embedded http server support on newer devices, it's advantageous to use something like XML-RPC to talk to them as it get around network configurations, fire walls, etc. (Could you image an "appliance" that demanded your firewall settings? Stuff should just work.) XML-RPC is great for this, you get a human readable "messaging" scheme over http and you can reuse the message pack/unpack code from design to design. However... In the embedded world all to often tcp/ip is not a transport option at all, or adding it to a design breaks cost targets. In those cases you still need to communicate with the device, but man it would be great to reuse all that message handling code again. So why not use the XML-RPC style of message formats, and handling over things like RS-232, RS-482/5 (which-ever one is multi-drop, I forget), IEEE1394 (firewire), USB, even shared memory pipes or just raw (non-http) sockets. So why not? You only need to use a different transport layer! It not strictly XML-RPC, but it smells a lot like it. And picture this, a "relay/dispatch" device that talks all those different transports and can "route" XML-RPC calls... Why not? > on Thu, 17 Jul 2003 07:44:01 +0100 "John Wilson" <[EMAIL PROTECTED]> > wrote: > > > rufio wrote: > > > > You cannot assume that lower protocol doesn't use XML. > > > > Yes you can - that's what the XML-RPC specification says. > > Abstraction of transport layer breaks the spec in general, cause we dont have > to use HTTP. Using jabber for transport is against the spec already. > > <cut> > > > > Yes but this isn't XML-RPC and XML-RPC is what the Apache code is > > supposed to implement. > > I thought the whole idea about abstracting the transport layer was breaking the spec. > > You implement XML-RPC only in the default plugin, the rest is just a framework, a > code that does common things and if you support different transports, putting the > prolog into message isn't common, because > > > > You cannot assume that lower protocol doesn't use XML. > Please do, in this one regard, make it *possible* to "break" the spec just a little bit. Regards John Volkar Senior Software Development Engineer Mckesson APS Research & Development 1-412-209-3828 ---- Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.