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.""
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".
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.
It's 10 PM. Do you know if you're un-American?
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 XML-RPC.com!
--8<--
--8<--
Use the "dcop" command at the shell prompt! Or use the graphical KDE dcop browser "kdcop"! Wonderful, huh?
/etc/motd true". Wonderful!
For example, run kwrite and then type "dcop kwrite" at the bash prompt. And then type "dcop kwrite KWriteIface loadFile
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)
(Please browse at -1 to read this comment.)
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.
Jon Erikson, IT guru
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.
-- the most controversial site on the Web
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.
--
The real Webmaven is user ID 27463. I don't rate an imposter, because my ID is such a lame-ass high number.
is there anything it can't do?
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
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.
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.
Jon Erikson, IT guru
There are several XML compression formats out there already; it's too bad people haven't decided on one, though.
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 ;)
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"....
...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.
-jpowers
-jpowers
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...
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.
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.
I used up all my sick days, so I'm calling in dead.
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.
Trolls throughout history:
Jonathan Swift
In the example
/WINTON HTTP/1.0
<methodName>example.setState...
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 ?
POST
...
<EXAMPLE>
<SETSTATE>
<USERNAME TYPE="String">Winton</USERNAME>
<BIRTHDAY TYPE="ISODate">10101963</USERNAME>
<HAPPY Type="Boolean">T</HAPPY>
<RETURNS Type="Boolean"></RETURNS>
</SETSTATE>
</EXAMPLE>
Cheers,
Winton
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.
When I hear the word 'innovation', I reach for my pistol.
> 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.
Bruce
Bruce Perens.
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!
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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.
--Blair
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.
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.
Don't forget the hardware XML accelerators for just such occasions.
Vintage computer games and RPG books available. Email me if you're interested.
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.
No.
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!".
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.
If it was said on slashdot, it MUST be true!
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?
A deep unwavering belief is a sure sign you're missing something...
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
</sarcasm>
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.
Alex
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
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
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?
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
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.
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.
--
Xenu loves you!
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!
Where's the documentation for the DCOP interfaces that apps support? I looked on developer.kde.org 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).
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.
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.
.xmlc or something. Then include the xml parser and compressor/decompressor code into standard libraries for all platforms.
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
cryptochrome
---If you can't trust a nerd, who can you trust?
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.
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 <granroth@kde.org>
#
# 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.
#
#!/usr/bin/python
from xmlrpclib import *
import os
rc = open(os.environ['HOME'] + '/.kxmlrpcd', 'r')
config = string.split(rc.read(), ',')
port = config[0]
auth = config[1]
server = Server("http://localhost:" + port +"/xmlrpcDCOP")
print server.types.currentTime(auth)
print "Kurt Granroth <" + server.email.lookup(auth, "Kurt Granroth") + ">"
print "Adding Joe User <joeuser@host.com>"
server.email.addAddress(auth, "Joe User", "joeuser@host.com")
print "Joe User <" + server.email.lookup(auth, "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)
(Please browse at -1 to read this comment.)
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
Shell script is easier for some folks:
//g'`
/kdesktop HTTP/1.0
# This file is part of the KDE kdebase package
#
# Copyright (C) 2000 David Faure <faure@kde.org>
#
# 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.
#!/bin/sh
port=`sed -e 's/,.*//' ~/.kxmlrpcd`
auth=`sed -e 's/.*,//' ~/.kxmlrpcd`
cat > cmd.xml <<EOF
<?xml version="1.0"?>
<methodCall>
<methodName>KDesktopIface.popupExecuteComman d</methodName>
<params>
<param>
<value>$auth</value>
</param>
</params>
</methodCall>
EOF
length=`wc -c cmd.xml | sed -e 's/cmd.xml//;s/
cat > head.xml <<EOF
POST
Content-Type: text/xml
Content-length: $length
EOF
( echo open localhost $port
sleep 2
cat head.xml cmd.xml
sleep 2
) | telnet -8E
(Please browse at -1 to read this comment.)
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).
-M
You're smart; why haven't you learned Python yet? diveintopython.org