Slashdot Mirror
ESR On XML-RPC
daveuserland writes "Eric S. Raymond has discovered our XML-RPC project, going strong since early 1998. I don't think XML-RPC has ever been discussed on Slashdot. It's one of the most ambitious and successful open source projects, but not from the usual suspects. Raymond says: "XML-RPC is very much in the Unix spirit. It's deliberately minimalist but nevertheless quite powerful, offering a way for the vast majority of RPC applications that can get by on passing around boolean/integer/float/string datatypes to do their thing in a way that is lightweight and easy to to understand and monitor. This simple type ontology acts as a valuable check on interface complexity.""
There are several XML compression formats out there already; it's too bad people haven't decided on one, though.
People interested in XML-RPC might be interested in checking it out using KDE. Since KDE 2.0 a DCOP XMLRPC bridge has been included allowing easy access to a wide range of the desktops APIs.
Rich.
How about this: /etc/termcap
$less
######## TERMINAL TYPE DESCRIPTIONS SOURCE FILE
#
# Version 11.0.1
# $Date: 2000/03/02 15:51:11 $
# termcap syntax
#
# Eric S. Raymond (current maintainer)
# John Kunze, Berkeley
# Craig Leres, Berkeley
#
# Please e-mail changes to terminfo@thyrsus.com; the old termcap@berkeley.edu
# address is no longer valid. The latest version can always be found at
# .
You'll see it from time to time, Eric did this little bit, Eric did this little bit. He shows up on linux-kernel from time to time. It adds up. Have you looked at termcap recently? JHC, I wouldn't touch that nonsense with a 10 foot pole. But he does. Same goes for his rewrite of the kernel configuration file system. Nutso stuff that is way beyond either of our abilities (admit it, you lamer), and he's working on it right now. I may not be the biggest ESR fan on the planet, but he has made many positive contributions, and his heart is in the right place.
I'm a software architect for a major bank, where I design and implement the primary app used by all bankers to open new accounts. It's a web-based app written almost entirely in Java and Perl. A pretty monstrous app, under heavy load and very high profile. We decided to use XML-RPC for interprocess communication between our JVMs and Perl CGI's. We found the Java-based XML-RPC server (at least the one we looked at) to be in need of serious help. Exception handling was poor, and there were some significant performance issues. The perl client had similar problems. However, after a couple of months of working with it, we were able to tune it enough to support our demands, and our app is demanding (20 to 100 heavy-weight hits per second, with at least 1 XML-RPC transaction per hit). XML-RPC has greatly simplified RPC between our JVM and Perl CGIs, and has made complex interactions a breeze to code. Once the exception-handling and performance issues were addressed, we realized that we had an unusually effective piece of RPC software on our hands. We no longer fear Java-to-Perl RPC. I highly recommend it. We hope to release our fixes out to the public sometime soon.
We use XMLRPC in one of our enterprise-(ish) applications for webbased API calls. Works very well. As for SOAP, SOAP more or less does the same thing; except it's more of an "enterprise" solution. Microsoft is one of the big bangers behind SOAP, and numerous other large companies such as IBM (and sun, sorta).
The problem with SOAP, is it's not really done, and it doesn't really work. So we decided to go with XMLRPC (because it works), and eventually replace it with SOAP once the standard stabilizes and there's actual functional implementations.
One example of XMLRPC not being quite ready for prime-time, is it's lack of Null support. As the article described XMLRPC allows the passing of primitives and some complex datastructures nativly (strings, lists, hashes, ints), but it does not support passing nulls. Anybody whose tried to use XMLRPC will spend about an hour scratching their head when they program an XMLRPC call which (in java or C) has a return type of void (such as a setter for a variable). XMLRPC will choke because it can't describe a Null. So you end up having to return blank strings to work around the problem.
You know some XMLRPC specifications guy just slapped his head when he read this saying, "dammit, I knew I forgot something!".
So, despite the community's protest that people are needed to do things other than write code, the one criterion that you express is that what ESR wrote ISN'T HARD ENOUGH. And then you get modded up in a reply, suggesting that the community agrees with you. You know, the most damning writers at ZD have figured it out. The open source community ensures that end users are systematically locked out. The community has a genuine contempt, not only for "users", but also for the simple. And so it produces sendmail -- and a whole set of similar interfaces that are so complex to configure that you need more 3" thick O'Reilly books. ESR is not given some respect for having coded a utility that you don't care about. ESR is given respect because he helped a gigantic and very powerful set of users to understand the revolutionary and important nature of open source. If open source fails at its alleged "mission", we will be running Microsoft (TM) TCP-IP.NET by 2005 and the state of freedom across the world will be endangered. (OK, allow me a little melodrama.) But ESR will be responsible for holding off that state of affairs for a few years. Do you believe me? Do you care?
It is good to hear ESR's views on this subject too - he is an articulate and interesting writer.
--
Clarity does not require the absence of impurities,
/* And you'll never guess what the dog had */
/* in its mouth... */
--Larry Wall in stab.c from perl
As I understand it, SOAP evolved from XML-RPC. See: http://www.develop.com/soap/soapfaq.htm#22 for a hint at history and ancestry.
I'm of a mixed mind about both SOAP and XML-RPC. XML-RPC includes explict typing of passed values, and SOAP does not. Point to XML-RPC. XML-RPC is substantially simpler than SOAP. Point to XML-RPC.
I bet SOAP wins, because it's heinously complicated. Big companies and big devel shops love complicated: it raises the cost of entry into a market where the complicated standard prevails.
XML-RPC predates SOAP by a few years, and has more implementations, and has demostrated interop. SOAP, which I am also a co-author and supporter of, has not yet reached substantial interop, and this is going to be a bit difficult, but we'll get there. You're right that SOAP has more support from large companies, and that's great, but as an independent developer who doesn't want to be controlled by the large companies, I think XML-RPC provides a valuable insurance policy. I'm very happy to get ESR's endorsement of XML-RPC.
Yes.
ESR's coding contributions have some genuine measure of usefulness. He sweats details (like little bugs, documentation) that other open source projects gloss over.
His philosophy is also interesting and insightful. The problem, of course, that whatever amount of insight and creativity he has is finite and becomes wearily diluted when hyped in the media. The same problem would afflict any "visionary" the media happens to glorify.
Regarding XML-RPC, I figure SOAP has become the next incarnation for better or worse. I've heard it's got chrome tailfins, but the same essential useful concept under the hood.
"Provided by the management for your protection."
Saw this over on LinuxToday.
Zoom over to Google and put in Eric Raymond (or just check this link out). Notice the paid hotlink...
Linux - Because Mommy taught me to Share.
Anyone see any errors in this thinking?
Yes. It's true that as a consequence of its text-based nature, communication via XML is decidedly more bandwidth-intensive than any binary counterpart. The problem, though, lies in translation of that binary format two and from different machines, architectures, languages, and implementations.
I currently do quite a bit of work using SOAP, which is similar to XML-RPC, but a little less well-developed. It's a no-brainer. If I'm using Java, Perl, C, C++ or even Python, it's relatively easy to make calls between these different languages. I don't have to worry about the endianess of the data I'm working with. I don't have to worry about learning some new data encoding scheme (XML is very well-defined, and very ubiquitous; almost every language has a translator). Communicating between a language like Perl, which has no typing, and Java, which has more strict typing is a no brainer, because the data structures are defined by a well-documented, human readable schema, and when I look at the data I'm sending, I can see the raw information.
Bandwidth concerns might have been paramount two years ago, but the world in which XML-RPC and SOAP are being used has already shifted to broadband. Now, human clarity and complete interoperability, as well as the ease of use of porting XML-RPC (or SOAP) constructs to another language (since it's just XML text) make it a much more efficient model in terms of programmer time.
Yes, from a strictly bandwidth concern, CORBA or DCOM beat XML hands down, but when you remove that consideration, it's not that big a deal. Couple it with existing protocols (I've seen SOAP implementations via HTTP, FTP, and even SMTP), and the opportunity to grow via existing infrastructure and well-known technologies, and you just have an easier (and thus, I would argue, more open) model to work with.
The biggest technical security risk in most environments is that Bad Guys can hand programs input that doesn't have the properties that the programs' authors expected, and in networked environments (such as an RPC) there are Bad Guys all over the Solar System who have the means of handing input to your programs (both client and server), and RPC mechanisms have been a popular target for crackers, not that networking in general isn't a target-rich environment. Anybody who provides a new general RPC mechanism and doesn't make the default behavior to be "secure" at least to the extent of safety-checking input is a danger to the community. I don't see any evidence that XML-RPC addresses this problem.
The great thing about XML, besides flexibility and popularity, is that it provides a mechanism for defining valid input, through the use of Document Type Definitions, so parsers can determine whether input is both well-formed and valid. That doesn't mean that everybody writing a program that uses your XML DTD will write it safely, or even if they use a parser that they'll refrain from mismanaging memory, but at least they'll all have a consistent spec for what they need to support, and if they've got an xml parser that they're using, it'll have something to work from.
The XML-RPC Spec doesn't provide a DTD, and provides examples that don't use it. They don't say what resources a conforming call might use, and is pretty sketchy about responses to invalid calls, as well as about what to do with non-existent or invalid responses. Of course, it does help to use an XML parser that itself responds safely to maliciously designed inputs, but that's a job for open-source commonly used code, just as any XML-RPC toolkit built using it is. But with no DTD, it's harder to decide if requests are malformed or invalid, so the author's program needs to do that work itself, which means that 25% of the popular packages won't even bother, because the deadline for the next release is coming, or the overhead of the XML parser makes the dancing pigs GUI skin too slow. And it only takes one widespread dangerous application to carry the next internet worm - you don't want QuakeSter OpenMusic&WeaponsAuction to start DDOSing metallica.com because a buffer overflow in the PayLars feature lets bad guys in (and the distributed database that replaces Napster makes it easy to find people running that client.)
Please, there are so many loose ends on this stuff - give it a full-scale spec, and build enough documentation and API tools that encourage safe use and strongly resist unsafe use. (Of course, that's harder than it sounds - the obvious way to protect against buffer overflows in an environment where all the input is character strings is for the API to (safely, with checking) malloc (or language-appropriately-create-objects) any input objects, so the malicious client can probably find some good resource starvation attack, but that's at least a Denial Of Service rather than an attack that lets the bad guy hand the server some code to run.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Yes, he has a big ego which he's not afraid to let show (at least in his writing, he may be a wallflower in person for all I know), but so do a lot of other people who have done considerably less than he has.
Sure, don't treat the guy as some kind of god, but don't ignore him just because he's not the flavour of the month any more.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)