Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Unix Operating Systems Software


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.""
This discussion has been archived. No new comments can be posted.


Comments Filter:
  • Well, Bill Joy says XML is no good because it's just data (no behavior), ESR says it's cool because it's minimalistic. If I had to choose based on the personalities, I would definitely take the side of Bill Joy, but we all know that "incomplete but simple" has always triumphed over "complete but complex".
  • If you want a DTD for XMLRPC then look at []. This page has a link to the DTD I wrote when I first got interested in using XML-RPC, the DTD is now maintained by Fred Yankowski.


  • You DON'T want RAR for stream compression...well, at least not "solid" RAR archives. LZ78 (or whatever zip uses) is just fine for text, which is what xml is. Please, not Yet Another Cross Platform Standard For Something Or Other.
  • i don't see it. either it's gone or i'm missing it.
  • My biggest issue is that for XML-RPC to support things that are the biggest issues of distributed computing (e.g. keeping track of state) would add so much bloat to the XML parsing, string building, etc process for making a remote call as to make it unfeasible.

    I think XML-RPC is to be used for basic stuff like finding out what MP3 someone is listening to or getting a relevant subset of some site's content that you can parse easily for inclusion on your own site. It's probably not (as you say) good for clusters and so on... But I don't think it's proponents want it to be used for that either...

    Read more about it at []!


  • Way cool! A non-flame answer :)

    Okay, if you want to know what an object is, and why its not a collection of data, place refer to a book on OOP. If you still don't understand, don't bother to continue this conversation - you obviously don't see the benefit in OOP for your purposes or applications, so there's no point in forcing it on you.

    Also, once you've read up on OOP, you should understand the difference between returning an error, and throwing an exception. They are entirely different programming constructs.

    Object discovery is the idea of using a registration or naming service. You tell a server that "I have an object [here] that conforms to interface [xyz]". Its a combination of CORBA's Interface Repository and directory services.

    Yes, you can implement a service service to do this for you. That's exactly the problem - your implementation is not a standard. XML-RPC is that and nothing more - its RPC over XML. It is a textual representation of a binary data transfer to invoke a procedure that is not executed locally. If that's what you want, that's what you get. BUT XML-RPC is not toted as "just another RPC" ... its the standard solution to all your distributed communications problems.

    Bullshit. It solves ONE of the multitude of problems associated with distributed computing. CORBA has 12 different aspects to it - communication (which is what XML-RPC does, and nothing else) is just one of those 12 aspects.

    My point was not to say that XML-RPC doesn't work. It was to say that XML-RPC is shortsighted. It doesn't do what it SHOULD do to facilitate distributed computing.

    As for the XML-RPC spec, it specifies that XML-RPC works over HTTP. It specifies expected responses from the HTTP server (as part of the HTTP protocol). It also doesn't include a DTD or any other formal/rigid specification of dialect. The specification is a set of examples that is mostly cohesive, but no substitute for The Real Thing. If you really want it to be a standard, why not release an RFC about it containing a DTD or BNF description of the protocol?

    I agree that you should examine requirements and determine the best tool for the job. I believe that neither of these protocols is a good tool. XML-RPC could be so much more (and still remain simple) if it widened its eyes to the problems of modern computing, and didn't sit solving problems that have been solved a thousand times already.

    Add proper exception handling and object addressing to XML-RPC (that's one additional return type and one additional request attribute) and you've got most of the power of SOAP. Now specify that XML-RPC is meant to (but doesn't have to) work within a framework that considers object discovery, security, and so on, and define some standard interfaces to support this functionality, and you've got a decent system.

  • 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.

    The advantage of distributed object systems like CORBA, DCOM or RMI over XML-RPC is a lot more than bandwidth. The problem is that distributed computing faces a lot of issues like transactional behavior, security, robust error recovery, object persistence plus a bunch of other issues that involvetracking state across sessions and I'm not sure how throwing in a bloated protocol into this mish mash is truly beneficial.

    Now if it's just comparing regular RPC to XML_RPC then it can still be argued that adding the bloat of XML-RPC so that calls can work across systems or languages is not worth it considering how rarely real cross platform distributed computing is done.

    Finagle's First Law
  • irregardless

    adv. Non-Standard


    [Perhaps from ir(respective) + regardless.]

    Usage Note: The label Non-Standard does only approximate justice to the status of irregardless. More precisely, it is a form that many people mistakenly believe to be a correct usage in formal style but that in fact has no legitimate antecedents in either standard or nonstandard varieties. (The word was likely coined from a blend of irrespective and regardless.) Perhaps this is why critics have sometimes insisted that there is "no such word" as irregardless, a charge they would not think of leveling at a bona fide nonstandard word such as ain't, which has an ancient genealogy.

  • Use the "dcop" command at the shell prompt! Or use the graphical KDE dcop browser "kdcop"! Wonderful, huh?

    For example, run kwrite and then type "dcop kwrite" at the bash prompt. And then type "dcop kwrite KWriteIface loadFile /etc/motd true". Wonderful!

    You can do so much scripting with this information

    dcop kwrite KWriteIface
    QCStringList interfaces()
    QCStringList functions()
    void cursorLeft()
    void shiftCursorLeft()
    void cursorRight()
    void shiftCursorRight()
    void wordLeft()
    void shiftWordLeft()
    void wordRight()
    void shiftWordRight()
    void home()
    void shiftHome()
    void end()
    void shiftEnd()
    void up()
    void shiftUp()
    void down()
    void shiftDown()
    void scrollUp()
    void scrollDown()
    void topOfView()
    void bottomOfView()
    void pageUp()
    void shiftPageUp()
    void pageDown()
    void shiftPageDown()
    void top()
    void shiftTop()
    void bottom()
    void shiftBottom()
    int numLines()
    QString text()
    QString currentTextLine()
    QString textLine(int num)
    QString currentWord()
    QString word(int x,int y)
    void insertText(QString txt,bool mark)
    void setCursorPosition(int line,int col,bool mark)
    bool isOverwriteMode()
    void setOverwriteMode(bool b)
    int currentLine()
    int currentColumn()
    bool loadFile(QString name,int flags)
    bool writeFile(QString name)
  • This follow up appears to be only related to your limited sphere of knowledge. DCE-RPC and other non CORBA implementations suffer from the same problems (previously mentioned) as XML-RPC, there is no advancement in the technology, just bloat. All that XML-RPC done is taken the RPC concept and changed the protocol with a heavier one and the requirement that the server needs an XML parser. Again, why not just use CORBA?

    Extending interfaces is another solved problem. You simply version the interfaces, like you would in XML-RPC or any network application for that matter. The problem is still there, and is not uniquely solvable in XML-RPC. Reverse Engineering the CORBA protocol is ridiculous, the spec is published and well-known.

    I am not sure I have ever seen a DCOM library for *nix or MacOS. I have seen DCE-RPC implementations for *nix and MVS. As for CORBA not being on windows platforms (what about TAO, mico, Orbix, Orbacus), take a look at CORBA like XML-RPC will run on anything. It was designed that way.

    The short story is really, laziness/ignorance to engineer a proper protocol that won't hog bandwidth is not an excuse to reinvent the wheel as a square. I would grudgingly use XML-RPC for local machines and small LANS, and CORBA across the internet not the other way around. Both, can take advantage of SSL/TLS, both have authentication mechanisms, just one is more light weight, more robust, and is consistent across platforms. CORBA can accomplish any task XML-RPC can and more.
  • Wait, you're "out" but no one at your workplace knows you're gay? Did the meaning of, "out" change recently?
  • I can't remember the name, but a block north of Shoreline on El Camino there is a good place that serves up Gyros
  • Another article [] about XML-RPC

    According to Jeff Walsh's InfoWorld article, Microsoft is planning to open up their operating system using XML-RPC. Such a protocol could be deployed quickly in other operating systems that support HTTP, ranging from Perl scripts running on Linux, to Quark publishing systems running on Macs, to relational databases running on mainframe systems. It could put Windows at the center of a new kind of web, one built of logic, storing objects and methods, not just pages and graphics.

    If this is not just hype this could really allow Linux/BSD replace any NT/Windows machine

  • You say he still does real coding, and yet when was the last time we saw anything from him? Like RMS he seems to have become famous whilst only having produced a single piece of well-known code, but at least RMS has something he believes in.

    ESR seems to have recently decided that the best interests of Open Source lies in bending over and taking it from as many corporate CTOs as possible. Rather than actually getting down and doing anything (other than maintaining the pointless Jargon File) he spends most of his time either talking to suits or writing his usual arrogant drivel.

    ESR is just one cog who got a lucky break and tried to play it for all he was worth. He deserves no more attention than any other open source coder.

  • The XML-RPC HOWTO is here [].
  • ...but why use XML-RPC when SOAP exists and has more market noise behind it?

    Do you base all of your decisions on "market noise"? I mean, I understand wanting to support something that is likely to last, but jumping on the latest craze in the hopes that it will take off is not necissarily the best way to promote yourself in the software world.

    Granted, I'll give you that Java was once a huge risk, just as many other 'technologies' before and since, but the idea that the person with the biggest wallet to hand over to marketing is right just seems ludicrous.

    Marketing might does not make right. Sad that it might win in the end, but technology and marketing are usually at odds. Chances are real good that neither SOAP nor XML-RPC will end up being the be-all/end-all that they are supposed to be and each will simply become another tool to use in appropriate situations. Just be careful of the marketing noise, there have been a number of people that have gotten locked up when the heard a little too much marketing noise and started believing it.

  • "In the open source world companies will have to offer employees a greater level of meaning, something higher up the Mazlow pyramid. Basic job security and good compensation isn't enough." []

    ESR is a main board director of VA Linux, which dumped 25% of its "open source" employees today. Either he didn't know about the layoffs, or he knew and didn't care. Not sure which is worse.

  • "questionable sexual morals"

    What the heck you talking about? Or you just trolling through?

  • for instance, he's currently working on replacing the Linux kernel configuration system with something considerably better, from all accounts

    Where's this. I've looked at his home page and around but cannot find anything on it. Is there a link?

  • tomichj, The XML-RPC community looks forward to your fixes. :-) Thanks, Jim
  • Now if it's just comparing regular RPC to XML_RPC then it can still be argued that adding the bloat of XML-RPC so that calls can work across systems or languages is not worth it considering how rarely real cross platform distributed computing is done©

    Maybe it's not done because it's been so hard up till now© Maybe nothing good will come out of it, but I can't help but be excited, because a great many things will move from the realm of the possible, into the realm of the easy©

    In any case, it's now a hell of a lot easier to see what those remote calls are callin' for© That's got to be worth something in the debug cycle©

  • Show me an excellent and free CORBA implementation for Perl. Make it super simple to use for my super simple needs of having a Java client use my Perl based server. Now, make it easy to run the connection over SSL.

    Now I also need to call this perl stuff from an ASP based page using Visual Basic.

    This is what is nice about XML-RPC. It isn't the most efficient transport, but you don't always need the baggage that other protocols have.
  • $ kwrite &

    [1] 9716
    KWBufBlock: buildStringList this = 0x808fa88
    KWBufBlock: disposeRawData this = 0x808fa88

    $ dcop kwrite
    $ dcop kwrite KWriteIface loadFile /etc/motd true
    I thought you were putting me on at first, because the motd didn't appear until I typed a keystroke into kwrite.
  • If, like me, you have your companies intranet deployed on Zope [], then you need to check out the excellently simple Meerkat client for Zope []. It's a nice little utility that (among other things) caches the expensive XML-RPC queries to the Meerkat server.
  • by tedd ( 30053 )
    How does this compare to Microsoft's SOAP (Simple Object Access Protocol) []?



  • I agree. Part of the reason the web is so easy to deal with is the use of non-binary protocols. Think of http compared to something opaque and binary that might be theoretically more efficient.

    I'm happy to trade some plentiful and growing bandwidth for the ability to debug by eyeball. If you have a real need to maximize bandwidth utilization, this probably isn't the solution. But most of the time when I see people optimizing in this way, they're focusing on something that doesn't really matter in the grand scheme of things. Coders' time is expensive, as is debug and test time. Hardware and bandwidth are relatively cheap.

  • I'm more fond of the posts of "Lover's Arrival, Tha" and "Lover's Arrival, Thu". They make me laugh. Of course, so did "Lover's Arrival, The", but in a much sadder way.

  • XML and Soap parsing are not in the win2k kernel. MSXML.DLL parses XML and comes with IE 5. MSXML2.DLL can be downloaded separately. the .Net framework and a seperate standalone SOAP toolkit are also individual downloads.
  • is there anything it can't do?
  • First understand, I know perfectly well what an object is. I've been working with OO languages since C++ was first a front-end pre-processor for C. I have years of design and development experience in OO, and am highly compensated for that very knowledge. But that many years of experience results in the seeing of the base of these high level systems, and they are all the same. Kinda like the discovery of programming patterns by the Gang of Four.

    I was making the point that to any remote procedure call mechanism, be it RPC, RMI, CORBA's IIOP, XML-RPC or SOAP, what is important is the data being moved, not the fact that objects are being invoked. The company I work for (one of the DOW 30 to give you size) has a heterogeneous environment that includes everything from old DEC Business Basic to Informix 4GL to Java Servlets (with everything in between). I've implemented CORBA interfaces that invoke 4GL compiled RPC servers. We've designed and written C shared libraries for invocation from MicroFocus COBOL to perform HTTP POST/GET requests to servlets that then invoke CORBA objects. Did the COBOL code know it would talk to an object? No. There's no object there, just a back end message reciever that moves data. The idea is to build interfaces to existing applications that make them available to new code. I can do that with any of the RPC methods, but objects aren't required.

    To your points in detail:

    Object discovery is the idea of using a registration or naming service. You tell a server that "I have an object [here] that conforms to interface [xyz]". Its a combination of CORBA's Interface Repository and directory services.

    That's what I was saying. You are looking for an implementation of an interface (i.e. a method), not an object. Your code doesn't care what supplies the function. My comment was that the same thing can be accomplised with XML-RPC, so long as there is a recipient for the request (just like the actual Naming service implementation). Kinda like UDDI. I just make an XML-RPC call to a given recipient that tells me the URL of what I'm looking for. The details are stored someplace and my code knows the specific identification keys to ask.

    As for the next comment block you make, there isn't a standard implementation of a Naming service either. (I'm my companies representative to the OMG). There is a specification for how a Naming service will work with CORBA 3, but the OMG doesn't put out a standard service. All that is required for a standard service is an agreed upon query language for the requesting client. Once the query language is defined, it could be used by CORBA, RMI or XML-RPC. Nothing prevents me from making an XML-RPC call to a remote service object that calls a CORBA Naming service.

    CORBA has 12 different aspects to it - communication (which is what XML-RPC does, and nothing else) is just one of those 12 aspects.

    In actuallity, CORBA has one aspect: IDL. It is the definition of how disparate systems can communicate with each other in a language-neutral manner. From this, there have been IDL definitions of various services that a complete ORB should provide. Your ORB may provide a complete set of functionality (from BOA to POA to IR to Naming to Transactioning) but they don't all provide it. And when all is said and done, all CORBA Stubs and Skeletons do is translate object's attributes into byte streams (using a fixed byte ordering and sizing) to allow streaming those attributes back and forth. Objects (which are code AND data) aren't sent. Try serializing a Java Hashtable object to your C++ CORBA Client. Does C++ know how to re-build the object? No, but it can take the data from the object and put it in a C++ implementation of the same interface. (RMI is different. It can stream a Java class' actual bytes to be dynamically loaded by the remote VM).

    I also know that the XML-RPC spec indicates it works over HTTP. It was designed to as a means of invoking some message on some service in a simple (and firewall accessible) way. The header is specified for HTTP. What I said was that there is no reason it HAD to be HTTP. Granted, moving it to SMTP (for example) would break the spec as the header is now different, but all it is doing is moving TEXT back and forth. Nothing more. Look at the generated Stubs/Skeletons for any CORBA enabled code. You'll see that everything is moved as 8 bit bytes. Infact, a base function in most ORB toolkit's is StringToObject and ObjectToString (convert IOR's to objects and back again). It all moves TEXT back and forth.

    And as for error handling, the stubs and skeletons generally look for a starting ERROR indicator in the incoming data stream. Try throwing an exception from a client to a server. What happens? The Exception is turned into TEXT and streamed. It just happens that your generated code recognizes that type of stream and reconstitutes it into an Exception for you. That's just an layer on top of the streams interpretting the incoming data. No reason an XML-RPC library couldn't do the same, seeing as it has defined an error document.

    The point of all this is simple. All of these technologies boil down to nothing more than moving data from client to server over a byte-oriented transport protocol (normally some layer on top of TCP/IP). None are necessarily better or worse than the others. None actually move 'objects', they move data which the reciever (either client or server) reconstitutes into objects. After all an object is nothing more than data that represents state with an interface that knows how to affect that state.

    I've never seen where XML-RPC is touted as you say as

    its the standard solution to all your distributed communications problems.

    Anyone who makes a claim like that for ANY solution needs more experience. As I stated before, understand your requirements, use whatever tool does the job. There's no reason to use a dump truck when you can haul the load in a child's wagon.

  • 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.

    Yes, and that problem is solved by CORBA. One of the many jobs of a CORBA ORB is to translate from (the binary) IIOP protocol into a form suitable for your machine, architecture and language. Unless you are writting your own ORB you never even see IIOP. An ORB might be running on top of a completely different transport.

    CORBA is more than just RPC. It is an architecture which aims for platform independence and abstracting away from the details of how objects communicate. This includes a whole heap of extras like security, directory services, transaction services and other services that are necessary for a distributed system.

  • Recently, I stumbled across a book on XML that my ex-boyfriend left in my house in Bangor, Maine.
    I think XML is ideal for cross platform rpc calls. Parsing tools are comonplace. The xml format is simple, logical and extensible. It really seems like a wonderful idea.
    Plus the book smelled of his trademark espresso blend. The smell caused me to experience a wave of nostalgia that brought tears to my eyes, but I later recovered and found it an excellent technical reference.

    --Anticipation Of A New Lover's Arrival, The
  • If security is a concern in your environment either use something else or select a package that supports it. I know there has been work to integrate Kerbos as an authentication scheme. Check the email list for the Helma Java XML-RPC solution.
  • At least he signed up© Loser©
  • I wonder what these people think about SOAP []?

    It seems as though this otherwise worthwhile project has hit an obstacle - it now conflicts with an alternative, open protocol for remote procedures based on XML. And when you've got two competing systems, the best one will win.

    Unfortunately for XML-RPC, SOAP has the backing of a large proportion of the computing world, including both IBM and Microsoft. Whilst XML-RPC may be more in the "Unix spirit" it's a system that will be proprietary to Unix OSes rather than truly open.

    And given the amount of backing that SOAP is getting, it seems as though XML-RPC will be left behind and slowly forgotten. I'm not saying this is a good thing, but unless it can offer something that SOAP can, then it will simply lose to a better system. And at the moment, I can't see how it can match SOAP, let alone better it.

  • by Wesley Felter ( 138342 ) <> on Tuesday February 20, 2001 @03:27PM (#416111) Homepage
    There are several XML compression formats out there already; it's too bad people haven't decided on one, though.
  • by Anonymous Coward
    Try the examples in the KDE source (kdebase/kxmlrpc/test) It opens the 'Run Command' window, by talking to kxmlrpcd. You can control nearly all the KDE apps this way, via their DCOP interfaces. There are C++, Python and sh (yes!) versions to play with. Oh, you'll need KDE installed ;)
  • If you really want to use XML and Distributed Components in an even less practical way, check this out. []
  • by update() ( 217397 ) on Tuesday February 20, 2001 @03:34PM (#416114) Homepage
    For me, he stopped having credibility shortly after the flurry of Linux-related IPOs.

    I heard him talk a year and a half ago or so. He basically gave the same line he's used since 1997, with examples of free software projects that have succeeded and theoretical assertions that open development provides a better way to run a business.

    There was absolutely no acknowledgement that he's been pushing this line for years without a single prominent success, and that the project he was so eager to associate himself with, Mozilla, has nailed Netscape's coffin shut. People flame CmdrTaco all the time but at least his site addresses the failures of the open source model. Has Eric Raymond been seen anywhere near Mozilla since people started wondering when it was going to produce?

    Naw, he'd rather just keep talking about Linux and Doom and his *gag* "tribe"....

  • You're "out" but an "anonymous coward"?!?!?!?

    how fitting!
  • Want SQL Server access from Linux in XML form that is open source (GPL)? Check out ODBC Socket Server [].

    ODBC Socket Server exposes all Windows ODBC data sources via an XML interface and includes clients for every major programming language and environment under the sun!

    E-mail me if you have further questions at
    Best of luck,

  • ...transmission is a different story. We send lab data back and forth between locations, no one wants to link the databases at different locations, they use Oracle, we use Ingres, etc...

    I write a perl script that calls Ingres and assembles the data into an XML document, using a DTD we both agree to, then send them the document, their VB script uses the DTD to drop the data into their database and we're done. The only common dictionary is the DTD, a w3c standard one if possible. We can add as many people to this as necessary without having to force everyone else to conform to our dictionaries.

    In the last year we tried both the old way and using XML. The latter turned out to be much easier for the developers.

    As far as involving it in apps goes, I"d never store anything in XML, maybe config files or user settings or something. It MIGHT be useful for web stuff, we've been shifting our new pages over to xhtml trans ("mini-XML w/current browser compatibility").

    Also, our documentation people write the manuals in DocBook now, which is XML as well. What was nice about it was how easy it was to convert the whole archive of old Word Perfect documents into it, given a few tools and a nice scripting language. Since there are already a number of applications to handle it, I set them up to use the generic docbook DTD so if they want to try another application instead, they can do it without the WP->Word games we had to play up to this point.

    Since you like java, you should know that java's XML stuff is pretty decent, and the core of it got reused in perl's, I use it there. I think the real innovation wasn't the standard, but in convincing so many people to get their apps to support it. It certainly has the potential to make a few things a little easier (not easy, just easier).

    Anyway, it's not the be-all end-all solution to every problem ever, but it has been pretty useful for the few things we've used it with so far. I look forward to the day when the Mozilla/IE browsers are fully compliant with XML 1.0 so we can move the web page up to it.

  • Why reinvent the wheel when RPC already provides cross-language, cross platform remote procedure calls at much lower overhead?
  • Good thing ESR doesn't live in the hideously overpriced bay area... There are places where $300,000 will buy you a nice, new, 3000+ square foot house in a good neighborhood... Like a large part of the country.

    Next troll...

  • Cross platform distributed computing is the norm. You use SMTP and HTTP every day. It's why the net works. The closed binary formats of Microsoft applications are a nightmare to maintain and interoperate with. They are late to the show with SOAP.

    Stuff like error recovery, object persistence, etc., belongs at higher levels of an application stack, not at the request/response level.

    When an application's native format is XML, XML RPC is much easier to use than a binary format. When I persist to XML, and need to pump an object over the wire, I can just sendfile() and be done with it.

  • Except all the latencies of junk data going through the network is going add to a serious loss of productivity/revenue (user waiting... user waiting... user give up). Tell me that is cheaper than the programmer time.

    And is there proof that XML is going to be easier to program for than any other data structure?
  • It appears I misunderstood some of the XML-RPC protocol... Parameters are not named, so it has the same exact problems as DCE-RPC/DCOM and CORBA. Given how heavy the protocol is right now, you'd think that adding parameter names would have been trivial, and would allow them to avoid the stupidity of 'versioned interfaces'. Such a pity, I would've expected more from XML -- it could've made most versioned interfaces obsolete with such a simple extension.

    SOAP on the other hand, does appear to name parameters, and since it could be used as a transport for things such as CORBA instead of IIOP. I incorrectly assumed that because XML-RPC and SOAP shared a common heritage, that they shared the same features. A closer look at XML-RPC shows it's nothing more than a basic (very basic) marshalling protocol using XML for nothing more than formatting. SOAP on the other hand, could probably be used as a back end for almost all of the current RPC systems out there, including CORBA (that uses IIOP) and Microsoft DCOM (which currently uses DCE-RPC as it's transport).

    And as for reverse engineering, I was talking about figuring out what parameters an undocumented RPC uses/returns. Sniffing DCE or IIOP packets tell you practically nothing. Sniffing SOAP packets would clearly tell you the function names, parameter names, and types.

  • Will it be the same way for the proposed book The Art of Unix Programming?

    ESR says that he doesn't have the arrogance to think that he could write this book alone.

    But I bet he'd have the arrogance to only have his name on the cover.
  • "Fetchmail is supported on BSD, but NOT by the author."

    Um, might that be because BSD ports are usually supported by someone other than the author of the software?
  • XML-RPC (and SOAP) solves some problems that the binary RPC can't. Unlike most of the other RPC solutions, XML-RPC makes extending an interface without breaking other clients fairly seamless. DCE-RPC/DCOM and CORBA solve very different problems, since they're more interested in transparency above all else when making RPC calls. And as for interoperatbility, it'd be much easier to 'reverse engineer' a XML-RPC or SOAP call as opposed to DCE-RPC/DCOM or CORBA, since it is human readable, the parameter types and data are in-the-clear, and so on.

    If I wanted to do RPC between programs running on the local machine, or across a small LAN, I'd be much more likely to use CORBA, DCE-RPC, or any of the others, since this is what they excel at. On the other hand, if I wanted to publish services for third parties to use on the internet, I'd be more likely to use XML-RPC or SOAP, since THAT's what they're designed for. Platform neutrality is another thing I'd say that XML-RPC and SOAP would do better at -- nearly every platform has at least one library capable of performing those tasks, compared to the other RPC mechanisms. When was the last time you saw a DCE-RPC/DCOM library for *nix or MacOS? CORBA for Windows is similarly unusual.

    The short story is XML-RPC and SOAP won't kill CORBA or DCOM. They accomplish similar tasks for different purposes.

  • Like RMS he seems to have become famous whilst only having produced a single piece of well-known code, but at least RMS has something he believes in.

    I don't know much about RMS's GNU activities, but I always assumed he wrote EMACS and significant portions of GCC, the HURD kernel, etc. But I do know that he produced a TON of software before his GNU days in the Lisp world. Check out the last chapter of Steven Levy's "Hackers" for details on this part of his life, including a description of a year when he single-handidly matched the productivty of the world-class hackers of an entire company (Symbolics) that he felt was unethical.

    RMS can hack.
  • at least in theory.

    Per the spec, you can request a compression method to be used, without the user noticing anything. The trick is making sure the XML-RPC client and server both have the same stuff.
  • In the example


    Exactly how does one discover method names ? Also, there is some assumption regarding this name space syntax as being java like ?

    Likewise, what about return signatures ? Like what am I expected to recieve back if I return this.

    Final comment - what about semantic parameter annotation like "This value represents the name of the user".

    Maybe I'm missing something. I like the idea of getting away from worrying about bit-level encoding for languages, but I'm also worried that this spec isn't exactly clear.

    Why not just use full XML combined with some datatyping ?

    <USERNAME TYPE="String">Winton</USERNAME>
    <BIRTHDAY TYPE="ISODate">10101963</USERNAME>
    <HAPPY Type="Boolean">T</HAPPY>
    <RETURNS Type="Boolean"></RETURNS>

  • HTTP 1.1 and your friendly webserver and client can and do handle compression on the wire. So this is automagic for SOAP/XML-RPC.

    As for storing XML files, maybe if the application warrents it. Most of the XML work I've done has been Generate It/Send It/Throw It Away and Receive It/Parse It/Throw It Away.
  • > Like RMS he seems to have become famous whilst
    > only having produced a single piece of well-
    > known code

    RMS is the initial author of gdb, gcc and emacs, all three of which are major programs.

    ESR hasn't done any major projects (fetchmail is small), but have contributed to zillions of projects, like Netscape and Emacs.

    Both, of course, have done a lot of non-programming work related to free/open software.

    Feel free to disagree with them, or dislike their style. There is plenty to disagree with and to dislike. But both have earned respect by their accomplishments.
  • Well, it cost me 10 cents a click or something, so I shut it off when it got to $50 or so.


  • by Jason Earl ( 1894 ) on Tuesday February 20, 2001 @09:40PM (#416146) Homepage Journal

    What the heck are you talking about?

    Eric's stuff is everywhere. Take a look at the Acknowledgements file for Emacs, for example. Every time you fire up a debugger in Emacs, or edit a Makefile, or shoot off a cvs command you have Eric to thank. In fact, he apparently has more Lisp code in Emacs repositories than anyone besides RMS. He also wrote the keeper software for FTP supersite sunsite. He is currently working on a new build structure for the Linux kernel, and apparently some stuff for the PNG picture format. He is also active on the Python development lists (where he is pushing for wxPython over Tkinter).

    He also is a major contributor to Nethack. Which means he has been responsible for hours of my lost productivity.

    And that's just the stuff that I can think of off the top of my head, and it doesn't include stuff like the fact that he is maintainer of the Terminfo files, the Jargon file, and a whole pile of other stuff (if you haven't read the documentation for Intercal then you really are missing out). Oh, and let's not forget fetchmail. It seems he wrote an entire book on that particular experiment. If you are really interested in reading about the code he has contributed go here []. Most of the interesting bits are at the bottom.

    I don't agree with all of ESR's views either, but saying that ESR doesn't deliver is completely untrue. What's more, the software that he has written is quite well done. The documentation, in particular, is usually quite astoundingly good.

    The fact of the matter is that ESR is probably twice as talented a hacker as both you and I put together.

  • Egads! This is rad! As a Mac user, I've always reveled in the rad-ness of AppleScript, and felt bad for everyone else, who didn't seem to have anything like that was like it. I must say, this DCOP business is definately cool, and has functionality very much so like AppleScript events. Go KDE!
  • by blair1q ( 305137 ) on Tuesday February 20, 2001 @03:43PM (#416150) Journal
    Eric Raymond stopped being relevant for me when he stole the Jargon File and published it for his own profit without compensating either those who contributed or redirecting a nickel to any open-source organizations.

    After that, anything he has to say about communal efforts is the height of hypocrisy.

  • It's not.

    Frontier/Manila/Radio Userland all run on NT.

    Furthermore, the tightly integrated outliner/scripting language/object database that lies at the core of Frontier is bogglingly cool, useful, and fun. Dissing it as "legacy Mac stuff" is to ignore an outstanding example of something that has no equivalent in the Unix world at all.
  • by Rich ( 9681 ) on Tuesday February 20, 2001 @03:45PM (#416152) Homepage
    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.

  • by Ross C. Brackett ( 5878 ) on Tuesday February 20, 2001 @04:33PM (#416153) Homepage
    How about this:
    $less /etc/termcap

    # 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; the old
    # 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.
  • Don't forget the hardware XML accelerators [] for just such occasions.
  • A simple spec is nice and makes development easy for anyone with a computer to implement a simple xml-rpc server and client combo, but what about standards in marshalling the server code, state, transactions, and persistence?

    I have looked at several implementations of xml-rpc and non of them have been consistent in thier implementation. C/C++, python have server and client handling one way, perl has it another, and java has it another. Are any of these thread safe? A combination of Apache with mod_perl, mod_jserv/tomcat, zope or whatever could be, but then why not use a CORBA implementation which has all of these things and more (event service, property service, trading services, naming service)?

    Reinventing the wheel with a heavy application protocol on top of another doesn't make much sense to me. Remote proceedure calls are a solved problem, many times over (sockets, sunrpc, CORBA, EJB, DCOM, even CGI). xml-rpc is also in my opinion too little, and quite a bit late.

    CORBA like xml-rpc is platform independent and language independent. There are standards that can be relied on and it works. Using XML for everything from configuration files to application protocols to solving world hunger is inappropriate. Just because XML content is readable, doesn't mean it has to be used for everything. Just because http is everywhere doesn't mean it is the right protocol for the job at hand. I have found http is great at serving lots of information quickly, I have found it poor in recieving information, and recovery of connections and state.

    Finally, I know in CORBA that I can go from one vendors implementation to another and the methods used will be 99% if not 100% the same. The mechanical details of the name service and implementation repository maybe different, but the code will look the same.
  • by tomichj ( 158496 ) on Tuesday February 20, 2001 @10:21PM (#416162)
    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.
  • And this is willful misunderstanding of what Bill Joy is talking about.

    XML is being pushed by various yahoos as a way to achieve cross-platform compatibility. It doesn't. It provides a way to exchange data in a standard format, but nothing else. You still need some code to process the XML, and it is ideal for that code to be cross-platform to prevent vendor lock-in.

    If you think that XML (or XML-RPC) alone is sufficient, please show me an XML parser written in XML. All the non-fanboys will clearly understand why this is a silly statement.


  • by Leghk ( 30302 ) on Tuesday February 20, 2001 @03:56PM (#416168)
    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!".
  • In action, sure. Fetchmail has no pre-done BSD binaries, the maintainer of the port on FreeBSD is Vlle Eerola, and when he is talking in public, he rarely mentions BSD and Linux when discussing Open Source OSes....just Linux.

    But he has said on more than one occation (on tape in a public forum) that he feels that the BSD's should get more press than they do. He's also said that he feels the BSD kernel is better written/maintained. (don't believe that? How about the ESR e-mail to Linus where he suggests that the Linux kernel should move to a 'bsd model' and use CVS)

    ESR is in a position to promote non-GPLed systems, yet chooses not to. He gives lip-service to BSD, but doesn't put his actions where his mouth is. But giving lip-service to non-GPL systems is BETTER than most of the 'linux leadership' does.
  • And I thought CORBA was as far into the bonnies as you could get...

    PS> Now you know what Bonobo 2.0 will be based on. Slow, bloated, overkill? Perfect for GNOME ;)
    (No, I'm not a KDE bigot, both are fat walruses)

    PS2> Since when has XML become the solution to all of computing's ailments?
  • <sarcasm>
    His mountain of content-free Slashdot postings aside, does anyone think that Skyshadow still has a credible voice in the community? For me, he stopped having credibility long before he started bitching about ESR's relevence. I, along with a lot of other people, interpret his statements as arrogant, thinly-disguised, and frankly insulting whining (the exact stuff we love Linus for *not* doing).

    In any event, it seems to me that his role as a Slashdot karma whore could be easily taken over by any idiot.

    I know this is marginally off-topic, but I need to know if I'm alone amongst the serious /. inhabitants in not wanting to hear from this guy again (I already know what the trolls think), or am I just being too hard on a guy who still has something worthwhile to say despite letting the dollar-signs go to his head at one point?

    Seriously though, it's easy for you to belittle ESRs' accomplishments, but what have YOU done?

  • This is my experience with XML-RPC:

    I work for a company (Technisys []) which have created several years ago an RPC tool called "tmgen". This tool is built as a layer on top of rpcgen, adding session cookie handling, SSL support, a stateless server, handling of enumerated values with associated long and short descriptions, and many other thing. It's in fact, an application server built on top of RPC.

    This baby have been running for many years in the most important banks and credit cards companies here in Argentina (yes, you know the brands, but I'm not sure I can tell you which ones =) ).

    The "tmgen" tool reads a ".def" file that defines the datatyes, and ".trn" files which have the code of the different "transactions". Having read those files, it automatically generates the server source (including the rpcgen input source).

    I was asked to make it possible for the clients to be programmed in the Java language. I evaluated several possibilities, one of them using a Java client for RPC. This required us to go for a proprietary solution, besides, being in control of both sides it looked silly to be tied to a protocol. Another possibility would have been to modify tmgen to create an RMI server. But the best was to create an XML server (IMO). I then evaluated SOAP and XML-RPC. SOAP seemed very nice, but XML-RPC was *direct* mapping of the semantics and types of our existing solution. The benefits of SOAP were a drawback in this case, we just wanted to have strings, structs, ints and floats.

    So, now it's working. It takes a definition of the structs, the method and which parameters they get, and it creates code (using the gnome-xml [] library (which I recommend). The automatically generated code works as a standalone inetd webserver which reads an XML-RPC query from the net, parses the query, loads it in the generated C structures, run the "transaction", and creates a response from the reply structures. The final result was that all those old C, RPC-only, programs started to have an XML interface.

    I added the Helma RPC-XML client [] and voila, we had a Java client. So I must say that my experience in this legacy system with XML-RPC was great.

    Talking about new systems, I think that XML-RPC does the wrong thing, by defining markup for the types instead of marking the semantic of the data.

    I hope I haven't bored anyone with my experience.

  • I don't get how he ever became relevant. He is definitely involved in some coding, but relatively trivial. He was the first person to decide that the secret to Free Software was for businesses to get involved. Additionally, he created the concept (in words) of Open Source development which has YET to succeed.

    He talked Netscape into the Mozilla project. While I actually somewhat enjoy Mozilla, I find no reason to switch from IE at this time, and Mozilla shipped as Netscape 6 two years after starting, when his theory was that it would reduce development time.

    There are two theories, the mythical man month and the Bazarre theory. The Mythical Man Month was written after the management of a HUGE software project. The Bazarre theory was written after writing an e-mail downloader and a whim... As someone who has managed small scale projects, the mythical man month is totally true.

    I never understood how he became a spokesman. I don't agree with ANY of RMS's political theories, but I like his theories on software. I think that his contributions (GNU, the GPL, Emacs) are HUGE, while ESR wrote some essays.

    While both the tech writer and engineer are important to a project, the engineer is more useful. You can run a project without a tech writer (you'll suffer later, but it can be done), but try an engineering project without an engineer.

    His code contributions while nice, are trivial compared to the air time/free money he has received.

  • by Carnage4Life ( 106069 ) on Tuesday February 20, 2001 @05:16PM (#416175) Homepage Journal
    I am a big fan of distributed computing, heck I wrote an article about it on K5 [], and have always wondered what the XML-RPC payoff is.

    From what I can tell, XML-RPC is a way to replace the binary protocols that current distributed systems use (e.g. Corba's IIOP or DCOM's ORPC) with an XML based one. So when an object needs perform a remote method call, instead of just sending it's arguments in a compact efficient binary packet, it builds an XML string which has to be parsed on the other end. So with XML RPC, remote method calls now need the addition of an XML parser to their current bag of tricks.

    On the surface it seems that this makes it easier to perform distributed computing since any shmuck can use an XML parser and call a few functions. But it means that an extra layer of abstraction has been added to operations that should be performed rather quickly for the dubious benefit of compatibility across platforms (which is yet to be realized) which seems to be more jumping on the XML hype bandwagon than reality. My biggest issue is that for XML-RPC to support things that are the biggest issues of distributed computing (e.g. keeping track of state) would add so much bloat to the XML parsing, string building, etc process for making a remote call as to make it unfeasible.

    Anyone see any errors in this thinking?

    Finagle's First Law
  • by Tony Shepps ( 333 ) on Tuesday February 20, 2001 @05:28PM (#416176) Homepage
    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?
  • by Heidi Wall ( 317302 ) on Tuesday February 20, 2001 @02:51PM (#416178)
    I had not heard of XML-RPC until a few months ago, but I found XML-RPC for Newbies [] to be an extremely useful site allowing me to get up to speed on an interesting subject.

    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,

  • by Skyshadow ( 508 ) on Tuesday February 20, 2001 @02:51PM (#416179) Homepage
    Accomplishments from the fetchmail project aside, does anyone think that ESR still has a credible voice in the community? For me, he stopped having credibility shortly after the flurry of Linux-related IPOs. I, along with a lot of other people, interpreted his statements as arrogant, thinly-guised, and frankly insulting bragging (the exact stuff we love Linus for *not* doing).

    In any event, it seems to me that his role as a community mouthpiece has been largely taken over by the CEOs of the Linux companies, who I see on TV all the time (TechTV and the various financial networks).

    I know this is marginally off-topic, but I need to know if I'm alone amongst the serious /. inhabitants in not wanting to hear from this guy again (I already know what the trolls think), or am I just being too hard on a guy who still has something worthwhile to say despite letting the dollar-signs go to his head at one point?


  • by Philbert Desenex ( 219355 ) on Tuesday February 20, 2001 @02:52PM (#416180) Homepage
    As I understand it, SOAP evolved from XML-RPC. See: 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.
  • Well, as I recall, XML-RPC was the origin of SOAP. So hopefully SOAP will replace it, but that just means that XML-RPC did its job well.

    Actually, I hope that XML-RPC will wind up being a proper subset of SOAP. That would be convenient.

  • This triumph is discussed in detail in Richard Gabriel's famous "Worse is Better []" (part of "Lisp: Good News, Bad News, How to Win Big"). It's not necessarily always a bad thing.
  • by darrint ( 265374 ) on Tuesday February 20, 2001 @04:12PM (#416191) Homepage
    I've long thought that ideas such as XML RPC need to be somehow connected with the CORBA world.

    At first glance, it seems like CORBA is the better technology. IIOP is at least a little bit lighter on the network. An application built on a capable ORB can be switched to different local and remote transports with little or no modification. That can get useful.

    But, I think that some bridge should exist between GIOP and XML RPC and it's http relatives. GIOP over XML RPC? An IIOP to (XML)IOP bridge daemon?

    I've had situations where I had to contact MS SQL Server 7 from Linux. (Way to many) Easysoft gets the job done, but not in the way I want. I'd be happier if some CORBA/XMLRPC bridge existed.

    When I need to grab and process data I could write a simple cgi on a webserver running on NT. It would parse the XMLRPC REQUEST and grab a bunch of data for me and spit it out into XMLRPC. As needed I could rewrite these things as ISAPI dlls, NT Apache/mod_perl programs or even ASP scripts, depending on performance needs.

    Ultimately I could have written an NT network service that was dedicated to just my data, and used plain IIOP. My app on linux would need no modifications.

    Anothe way to look at the benefits is that you have CORBA when you want network transparency and XML RPC when you are willing to fiddle with the bits but are too lazy to implement IIOP and friends yourself.

    Now I will say SOAP. There I said it. SOAP SOAP SOAP. I got chewed out one time on the ORBit mailing list. The guy accused me of being obsessed with buzzwords but I think it's really because I said SOAP.

  • I've used XML-RPC before, written my own version of it, and used SOAP extensively (and even posted a few patches to the IBM SOAP for Java implementation). My conclusion has been that while RPC is slow, XML-RPC (and its variants) are necessarily slower. The idea itself is good, and it may be useful for so-called "web services" where there is a strict client-server relationship between communicating machines and there are few RPC's bouncing around the network. However, the overhead of a full XML parser, plus a protocol implementation, plus a marshaller and demarshaller to and from XML (especially since no language really provides this) is a big problem for XML-RPC and its kin. According to Dave Winer... "Conceptually, there's no difference between a local procedure call and a remote one, but they are implemented differently, perform differently (RPC is much slower) and therefore are used for different things." Bzzt! A local procedure call can pass references, pointers, etc. A remote procedure call is not just slower, but it also limits what kind of data you can reasonably expect to pass in the parameters. A pointer to a database driver, for instance, or a function pointer (for callbacks) are entirely different beasts! From the slashdot header: "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" Lightweight? Simple to understand and monitor? First of all, XML parsers are NEVER lightweight, especially if you want to do SOAP and use things like namespaces. Second of all, if you're doing only booleans/integers/floats/strings as the above suggests, then you're fine. More complex datatype marshalling? Ouch! I'm going to leave XML-RPC, SOAP, and its kin behind for a while and see what happens. Until then, caveat earlius adopterus!
  • by AMK ( 3114 ) on Tuesday February 20, 2001 @04:21PM (#416194) Homepage
    See recent python-dev summaries for what ESR is up to. Such as this one [] (adding string methods) and this one [] (speculating about Tk's fate).
  • Well, I have to agree, Since microsoft have effectively done the right thing, and put SOAP and XML into the w2k kernal, it is easy to see why SOAP will win in the marketplace.

    Of course I realise this is slashdot, and pandering to the marketroids is tantamount to heresy, but it needs to be said.

    For this XML-RPC effort to succeed, it needs to be implemented as a kernel-loadable module, and be included in the default Linux kernal.

    Then and only then will Linux be fully riding the XML bandwagon

  • Where's the documentation for the DCOP interfaces that apps support? I looked on and found docs on how to use DCOP, but nothing about what messages are understood by different apps.
  • I'm working on a C/Java project that uses plain old RPC (yes, there are RPC implementations in Java), and it works reasonably well. This topic puzzles me. What exactly does XML-RPC have that justifies a whole new method of doing remote procedure calls? That is, apart from the extra overhead and bypassing firewalls (thus negating their usefulness).
  • by daveuserland ( 315086 ) on Tuesday February 20, 2001 @03:03PM (#416205) Homepage
    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.
  • by 4of12 ( 97621 ) on Tuesday February 20, 2001 @03:03PM (#416206) Homepage Journal


    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.

  • by miracle69 ( 34841 ) on Tuesday February 20, 2001 @03:05PM (#416207)
    Saw this over on LinuxToday.

    Zoom over to Google and put in Eric Raymond (or just check this link [] out). Notice the paid hotlink...
  • by cryptochrome ( 303529 ) on Tuesday February 20, 2001 @03:05PM (#416208) Journal
    XML was designed to transfer data between programs and across platforms. The cross-platform clarity and reliability is great, but an XML file is really bloated relative to a specific file format, which is hardly conducive to transfering files.

    Those folks ought to incorporate a universal, cross-platform standard for compressing XML files into something a little smaller and more portable. Maybe call them .xmlc or something. Then include the xml parser and compressor/decompressor code into standard libraries for all platforms.

  • As many of the discussions to at the ol' SlashDot do, this one has devolved into ESR and XML bashing. XML-RPC isn't about conversing bandwidth or saving CPU cycles. It's about cross platform gateways. It's about using whatever language you want to get to the service you need. It's about freedom.

    XML-RPC is *simple*. It is simple to use and simple to debug. There is a free XML-RPC library for ASP [], so that you can finally control Windows from a linux box. Both XML-RPC and SOAP should be strongly embraced by the Open Source community, not because of their CPU effeciencies (which are non-existent), but because of the *programmer* effeciency. It become really easy to snap together a bunch of applications (much like a pipe) using one or both of these protocols. Yes, there is even a C implement of XML-RPC for those that enjoy the compile-debug-edit cycle.

    Do have a look at this intro [] that I wrote about XML-RPC.

    Are thier problems with XML-RPC and SOAP? Absolutely, but nothing that clever hackers can't fix.

    Anyway, XML-RPC and SOAP are very much worth your time to look at.

  • While checking out XMLRPC and SOAP for the use in a project in our company I came to the following conclusion:

    - has a really small amount of tags
    - is really easy to use (straightforward)
    - libs are available for nearly every flavour of prgramming language
    - specs are there and seemingly final
    - lot of programs support it, there are even small cmd-line and gui test programs

    - has been passed on to the w3c
    - since then it has "evolved" and "evolved" and "evolved" ....
    - no final spec yet
    - no date for the spec yet to see
    - horrendous ammount of tags
    - not as straight forward as XMLRPC (at least to me)
    - nearly no support in libs or programs

    Anyway I used XMLRPC to connect java, visal basic an zope :-)

    BTW: there are (at least) three more protocols out there that no one has looked at yet ....
  • Uhhh... XML parsing in the kernel? Really?

    - - - - -
  • KDE 2.0 has an XML-RPC bridge that is launched by default. This is still the case in KDE 2.1.

    Eric Raymond may be interested to know that a SOAP bridge is also planned for KDE. He may also want to investigate the dcop shell interface kdcop for some interesting stuffs.

    Look in kdebase/kxmlrpcd and kdebase/kxmlrpcd/test for some very interesting stuff. Some sample c0d3:

    # This file is part of the KDE kdebase package
    # Copyright (C) 1999-2000 Kurt Granroth <>
    # This file is distributed under the BSD license. See the file "BSD"
    # in the subdirectory "licenses" of the package for the full license
    # text which has to be applied for this file.

    from xmlrpclib import *
    import os

    rc = open(os.environ['HOME'] + '/.kxmlrpcd', 'r')
    config = string.split(, ',')
    port = config[0]
    auth = config[1]

    server = Server("http://localhost:" + port +"/xmlrpcDCOP")

    print server.types.currentTime(auth)
    print "Kurt Granroth <" +, "Kurt Granroth") + ">"
    print "Adding Joe User <>", "Joe User", "")
    print "Joe User <" +, "Joe User") + ">"

    struct = {}
    struct['one'] = 1;
    struct['two'] = 2;
    struct['nine'] = 9;

    print server.types.returnMyself(auth, struct)

    server = Server("http://localhost:" + port +"/trader")

    query = {}
    query['ServiceType'] = "text/plain"
    query['Constraint'] = "Type == 'Application'"
    print server.trader.query(auth, query)
  • > Fetchmail has no pre-done BSD binaries

    Because it builds out of the box. If you insist on binaries, then I present for your downloading pleasure, t/ports/mail/fetchmail.tar

    which has been there all along.
  • by Hrunting ( 2191 ) on Tuesday February 20, 2001 @06:19PM (#416220) Homepage
    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.
  • does anyone think that ESR still has a credible voice in the community

    I am no more a member of the community than anyone else - *BUT* - I support virtually everything Ive read that ESR has written.


  • by billstewart ( 78916 ) on Tuesday February 20, 2001 @06:22PM (#416223) Journal
    I'm just starting to buckle down and learn XML, so I may have the occasional detail wrong and major clue missing, but I've got several decades of experience with bad security and inadequate design :-)

    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 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.

  • Shell script is easier for some folks:

    # This file is part of the KDE kdebase package
    # Copyright (C) 2000 David Faure <>
    # This file is distributed under the BSD license. See the file "BSD"
    # in the subdirectory "licenses" of the package for the full license
    # text which has to be applied for this file.

    port=`sed -e 's/,.*//' ~/.kxmlrpcd`
    auth=`sed -e 's/.*,//' ~/.kxmlrpcd`

    cat > cmd.xml <<EOF
    <?xml version="1.0"?>
    <methodName>KDesktopIface.popupExecuteComman d</methodName>

    length=`wc -c cmd.xml | sed -e 's/cmd.xml//;s/ //g'`

    cat > head.xml <<EOF
    POST /kdesktop HTTP/1.0
    Content-Type: text/xml
    Content-length: $length


    ( echo open localhost $port
    sleep 2
    cat head.xml cmd.xml
    sleep 2
    ) | telnet -8E
  • by f3e2 ( 235629 ) on Tuesday February 20, 2001 @03:11PM (#416227)

    We use XML-RPC on our Python []-powered intranet to grab headlines from O'Reilly's free Meerkat wire service [] via Secret Lab's free xmlrpclib [] module. Dave Warner wrote an excellent article on XML-RPC and Python here [], using Meerkat as an example of a real XML-RPC server.

    If Python is not your thing, there are XML-RPC libraries for PHP and Perl. Rael Dornfest wrote an excellent article on Meerkat's XML-RPC interface here [], with sample PHP and Perl code (as well as Python).


    You're smart; why haven't you learned Python yet? []

  • by Goonie ( 8651 ) <> on Tuesday February 20, 2001 @03:12PM (#416228) Homepage
    ESR's thoughts *are* worth considering. He still does real coding (for instance, he's currently working on replacing the Linux kernel configuration system with something considerably better, from all accounts), and he is a thoughtful and incisive writer - lets not discount the value that many of his writings have had.

    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.

Money is better than poverty, if only for financial reasons.