Archive of UserLand's first discussion group, started October 5, 1998.


Author:Mark Nottingham
Posted:9/16/1999; 7:25:29 AM
Msg #:11122
Prev/Next:11121 / 11123

Last summer the IETF ran this critique of XML-RPC. I think they missed that XML-RPC is merely a formalization for the body of POSTs to allow diverse scripting environments to connect over the Internet. There are lots of one-off solutions that only work for a single environment. The purpose of XML-RPC is to unify the one-offs, so we can do some building.

Thanks for the link, Dave - wasn't aware of this one, and it brings several issues (more to do with the protocol than XML-RPC) together in a nice way.

I don't see this draft as missing the point of XML-RPC, or picking on it in particular (although I don't know the history behind it). There are lots of people out there overloading the HTTP to do new and interesting things; I've done my fair share. XML-RPC is good (no, great) because it defines a central way of doing this that covers many, if not most, of these cases with a reusable umbrella implementation.

What concerns the authors and a lot of other people is that the HTTP is being used for things that it wasn't intended for; as they point out, it's getting to be a complex beast, with a lot of very subtle interactions. Stretching it to do things it wasn't designed for can have a lot of unintended, and unforseeable, effects.

Noone can deny the sexiness of doing RPC (and other things) over HTTP; HTTP is ubiquitous, easy to use (or at least it appears to be), and gets through firewalls easily (among other benefits pointed out in the draft). I don't think the authors were saying that it shouldn't be done, just that it needs to be done with a lot of forethought. Issues such as scalability, interoperability with different network components (such as firewalls, caches, L4 switches, etc) and current implementations, security and so forth mean that it has to be addressed very carefully.

I'm very confident that this can and should happen with XML-RPC/SOAP. A world without something like them would mean continuing use of ad-hoc tunnelling through HTTP, which is a Bad Thing. We just need to make sure that it's done right.

There are responses to this message:

This page was archived on 6/13/2001; 4:52:39 PM.

© Copyright 1998-2001 UserLand Software, Inc.