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".
Rich.
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?
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 XML-RPC.com!
--8<--
--8<--
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.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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
adv. Non-Standard
Regardless.
[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?
/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.)
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 http://adams.patriot.net/~tvalesky/freecorba.html 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.
No.
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
A Government Is a Body of People, Usually Notably Ungoverned
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
The XML-RPC HOWTO is here.
// TODO: fix sig
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.
------------
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
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
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.
The Web is like Usenet, but
the elephants are untrained.
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.
see http://msdn.microsoft.com/xml/general/soapspec.asp
ted
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.
Get your teeth into a small slice: the cake of liberty
News for turds, shit that splatters
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.
-- Erv Walter
is there anything it can't do?
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
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©
Make me aerodynamic in the evening air
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 ;)
If you really want to use XML and Distributed Components in an even less practical way, check this out.
Trolls throughout history:
Jonathan Swift
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!
Yep, I never spell check.
More incorrect spellings can be found he
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 fxml@excite.com
Best of luck,
Tyler
...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
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...
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?
Kill'em! Kill'em all!
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.
I used up all my sick days, so I'm calling in dead.
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?
Most linux distros ship with fetchmail. Yet ESR's fetchmail site has RPM's of fetchmail. Why have the RPM's on the fetchmail site, if distro's ship with it? Why not equal treatment for BSD and Linux on the home page?
/ 4. x-STABLE/packages/mail/fetchmail-5.6.5.tgz
Fetchmail is supported on BSD, but NOT by the author. When the author says BSD should have more support, then doesn't provide that support, how much credibility should said author get?
Oh and your link should be:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386
where you change the 4.x-STABLE depending on the system you have.
If it was said on slashdot, it MUST be true!
The advantage is that you can have your Perl client talk to your Java server in an object oriented way.
Irregardless is not a word...
"BTW: there are (at least) three more protocols out there that no one has looked at yet ...."
Well spill the beans man we are waiting.
War is necrophilia.
By the way, that's not an old persian proverb, its a saying of the Muslim Prophet Muhammad (so I guess its an old Arab proverb).
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
Suck up. LOL
More race stuff in one place,
than any one place on the net.
Why do you think of it as being proprietary
and not 'truly open'? Are you confusing
ubitquousness for openness?
For every problem, there is at least one solution that is simple, neat, and wrong.
----
Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
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.
Uh, why not just do something like:
<string></string>
That looks like a NULL value to me (typed, even).
I think this even works in Perl and Java. Not sure what C does.
> 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.
Isn't that giving Mr. Raymond way too much credit? I agree he was a part of a much greater whole.
My problem with him is that I don't agree with a good deal of what he says. I certainly don't agree with how he says it. He would not be in my top 20 list of open source community "mouthpieces", and for him to appoint himself as such is offensive.
Up until his series of idiotic writings (Take my job..., I am really rich, etc.) I didn't mind him. After those, he just leaves a bad impression & I shudder to think what dumb-ass things he is saying behind closed doors to government and industry leaders that can truly effect Linux, Open Source, and Free Software.
hmmm ESR is a "leader" and here in the US, we cannot do without "leadership". Or maybe he is an inventor? That's because he had to invent his own cryptic language for kernel configuration. But oh boy, did he have to also invent Noosphere ?
CL: You sometimes describe yourself as an anthropologist.
ESR: Yes. An anthropologist is a person who studies the behavior of human beings and societies, who studies how human beings form culture, how those cultures behave, how do they change overtime, how they adapted to different conditions. Most of the important things I've done have come out of considering the culture of computer hackers anthropologically. Focusing less on their technological artifacts and their programs, and more of the social machinery, less on the technological machinery that they used, and more on the social machinery that they created in order to support their behavior, and support their craft.
CL: When I first read your "Homesteading the Noosphere", I was impressed by your tone of analysis, because you yourself were a hacker and your analysis was very objective.
okay sorry about all this
Bruce
Bruce Perens.
I don't know if the average bit of Python code is cleaner than the average bit of Perl code. I don't know. I don't read Python.
However, saying that the average Python programmer is better than the average Perl programmer is totally biased. There is no proof, and if there were, I doubt it'd have anything at all to do with the cleandliness of either language. If anything, the "average" Perl programmer is less of a programmer than the average Python programmer only because the Perl programming community is so much larger, and Perl is so much more widely used. It's like saying the average Windows user is dumber than the average Linux user.
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.
When you crave a burrito, come to El Balazo in the Haight. Or the grocery in Mountain View at the intersection of Rengstroff & Old Middlefield.
But what I *really* hurt for is a Philly from Delaware Sub shops in Austin.
What did you leave behind?
I shudder to think we might have "Scheme schemas" soon... :)
I adblock all animated gifs.
Blessed be the prime numbered slashdotters
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.
XML is beyond lame, it's a wonderful new way to choke up the internet... why the sudden urge to start sending data around in 7 bit?! We're talking RPC calls, and all a program need is a well defined data structure, not one that's human readable. Representing int/float etc as digits instead of 4/8 bytes, right... some people deserve to be forced to use a 300baud modem on an XT for the rest of their live, it seems nobody cares about efficiency anymore.
/proc in XML in Linux kernel?!).
It might be a nice way to store documents (no more proprietory format), but it's becoming the most abused and hyped way of passing data around (and who was the really smart person that suggested representing the
Kill'em! Kill'em all!
Of all the people I know using open-source (GNU/Linux) code, I don't know any using Eric's stuff. I don't know any advocating Eric's philosphies, either. I've heard Richard Stallman, and I have disagreements with some of his views, but I know he's considerably more influential. I don't think Eric really delivers anything, whereas Richard usually has something meaningful to say. It's at least tangible enough for me to get a hold of and disagree with, if need be. Perhaps I'm just overly concerned with his love of guns to take his rants seriously. Or perhaps I'm too British :-)
Earlier today under that article about the XML book I was ranting about how XML was pretty bloated for an RPC language, and how a Scheme-like syntax would be better. :)
:)
I still feel that way. I respect ESR and everything, but I do think he's trying to pander to the suits, acting as a self-appointed "marketing guy" for the free software world. XML has been buzzworded, Scheme has not, so he's gonna heap praise on XML stuff.
I looked at the XML-RPC spec. It looks very compact and easy to implement... for an angle-bracket language.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Don't forget the hardware XML accelerators for just such occasions.
Vintage computer games and RPG books available. Email me if you're interested.
Not a flame, just a question.
Just because it CAN be done, doesn't mean it should!
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.
Not to mention the way he's unabashedly biased the Jargon File. Check out the entry for Python, if you want to see what I mean.
I realize ESR has done a lot more for ...urm...open source...as he likes to call it that I have, but I don't have an ego the size of New York City, either. That just bugs me.
Kernel Traffic, the linux kernel development newsletter, seemed to indicate that the idea has been welcomed, except for ESR's choice of Python as the development language, as many people are concerned that it means that you need a working python environment to build a kernel.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
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.
XML-RPC is many things, but calling "lightweight" protocol that converts for numeric bytes into 64 textual representation bytes (not counting the whitespace) and adds XML parser pass on each function call - is an exaggeration if I ever saw it. It's definitely not lightweight protocol. Oh, and I forgot - that's an HTTP layer on top of it. Now think about you needing just to call one of your programs from another and pass a number - would you think of a protocol that adds two pretty slow layers of abstraction on top of it, one making message 8 times as big and other further duplicating its size? I would not.
-- Si hoc legere scis nimium eruditionis habes.
First, I'm not a hacker yet only a first year student so feel free to correct/flame any misunderstandings I have. It seems to me that XML-RPC, and SOAP will be very useful to Microsofts .NET and the like. Outside of applications servers how useful are they?
IMO there is no demand for .NET but since programs like MS' Office suite can't really be improved anymore they're going to "create" a market for something else. So arguing about whether xml-rpc is better or not useless since what it hopes to accomplish is ultimately useless. Just like the aforementioned desktop channels.
Please view this statement as a question since I often don't know what I'm talking about.
My other sig is a Haiku
Just as an example - I work for one of the biggest virtual community sites on the net and we have a number of partners. For several reasons, we have to make calls to their systems or they have to call ours.
Do you think anyone uses CORBA for that? No way.
Using the XML and XML/SOAP, we typically can link together sites with completely different architecture just in couple of days. Thanks to the existing Perl, Java, C++ and other standard XML-parsers, this task is almost trivial.
CORBA is nice, especially as a topic for computer-science-type discussion. But XML-RPC/SOAP is something very practical, that's what really makes the easy jobs easy.
So you grab your data, plonk it into XML, compress it, send it, so the other side have to decompress it, then decode the int/float etc back into bytes, well, that's useful isn't it?
Kill'em! Kill'em all!
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.
In an ideal world, RMS would employ his many talents working for Microsoft, where he would fit right in, if it weren't for his troublesome ideology.
Then visual C++ would not suck so much.
RMS, although most people hate his 'holier than thou' arrogance and juvenile leftwing politics, and questionable sexual morals, can actually write code when it comes down to it.
How many of us can say the same ?
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?
I went to XML-RPC home page and what do I see? The sign of the Holy Spirit in the top right corner. Good God XML-RPC is a truly blessed architecture! Halleluyah!
Your pizza just the way you ought to have it.
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.
And Sun is in the act aswell with the recently released "java api for XML RPC"
did you just say your boyfriend? Isn't your name shoeBOY?? Are there any weird circumstances here (ie. You're using someone else's account?)
Yep, I never spell check.
More incorrect spellings can be found he
What are you talking about?
ESR has never seen a bar of soap.
Bowie J. Poag
Bowie J. Poag
Project Manager, System 26 GUI Component Stockpile
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!
Also, there's a good XML-RPC HOWTO and Meerkat HOWTO plus several XML-PRC related pages available at zope.org.
--
Unselfish actions pay back better
Cracker!
On a more serious note, what is the point of firewalls if the clients are wide-open to the world with various implementations of xmlrpcd?
- Steeltoe
http://www.debunkingskeptics.com/
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.
No. No. NO.
You simply version your interface. Or are you too stupid ? Its a well documented technique. VB developers have been using it for years. This problem is not restricted to CORBA.
Get a clue before posting trolls/flamebait comments like that.
I don't have time for this idiots.
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!
Amen. While XML by itself is fine, RPC just sucks for moving it.
The last thing the world needs is a billion different interfaces (RPC APIs) to our software and information. What we need instead is a common generic messaging/tuple-space interface. Luckily we've already got that in HTTP. I wish more people understood that, especially smart guys like Dave Winer.
Unfortunately, it backfired because he alienated the people who supported him the strongest.
Here is Joe Hacker, being made to work 25-hours per week on his dot-com's "next biggest thing" web rollout, and what does ESR do? He becomes the arrogant power-broker, continuing to give these tiresome, grandiose prophetic speeches of hype and propaganda that were all too common... thus, he tied himself to the times.
Frankly, his opinion seems irrelevant today as free software has progressed into a new era where people are actually doing things with it... rather than spewing visionary rhetoric about how great it is and world-dominance and the "revolution", whatever that was.
People (particularly programmers) don't care too much if you hype your own program or your own creation. I think most of us that have designed something creatively have been proud of what we have done and have shown a few people. Some of us have projects that are very popular because others have liked it. But, for someone else to take your program and slickly promote it for money is another thing. ESR's propaganda was taking the work that free software programmers have done over the past years and skewing it in a way that was media-friendly (e.g., nauseatingly, overly anti-Microsoft; great for getting publicity and generating controversy) and highly-unpalatable to the free software community. The media portrayed ESR as speaking for the ENTIRE community.
Thus, I don't think anyone is in that much of a rush to get ESR back as the self-appointed "official spokesperson" of free software.
--
The proof be here.
I'm halfway inclined to believe that out of all these posts, the only reason so many praise Dave Winer is because Slashdot is repressing the awful truth about Dave. Yadda!
XML-RPC and SOAP may be related, but they are two differnt beasts. Do you need to deliver a simple, functional set of function calls to get a project done and get money rolling in the door. Or, do you need to kill the project in development?
.com survive the fallout and what more can you say.
SOAP and xRPC complement each other. Just like there is a place for procedural programming and there is a place for OO you have to know which tool to use and when.
If you have a system you want to put an XML interface on you have to understand it before you implement your interface. If the system is already modeled in OO it may be a better idea to use SOAP, but if it is not organized and you can think of it in terms of function calls and procedures then xRPC is a much better choice.
It is much better to replace a buch of embedded SQL calls in a system with a xRPC setup than trying to squeeze into a poorly fitted SOAP architecture. On the other hand if you want to do some fun RMI/CORBA/DCOM kind of stuff SOAP is a great choice.
No, XML-RPC isn't the answer to all your distributed IPC needs, but if you need to do something simple that other people can pick up and run with quickly, this is a good answer. It's helping me make a
Rember pick the right tool and the job is immensly easier.
Everyone who was ticked off by ESR's belligerent essay on how-to-be-humble-even-when-you're-rich will be glad to know that he isn't! ESR is now worth $300k and change after the tax man gets done with him.
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?
He's obviously satirizing the infamous and quite moronic posts of "Lover's Arrival, The".
--
Soma: because a gramme is better than a damn.
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.
Because Perl rules. It is too powerful to learn anything else.
Dave
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.)
Unless I'm misreading the spec, XML-RPC is limited to ASCII text (a tiny subset of UTF-8). Talk about primitive! Now, let's see. That means I could use the "worldwide" Internet to create distributed apps that support English, Hawaiian, Indonesian, and Swahili. All other languages would require SOAP, which uses the full UTF-8 strings that are standard with XML. No wonder large corporations required a version for grownups: SOAP. ASCII just doesn't cut it anymore, especially on the Internet. Unicode is the only real option for serious developers.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
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.)
XML is just the industry's latest snake-oil.
As for SOAP ? What a crock of s**t. CORBA did it better, and is an open standard.
Why is the computing industry such a joke these days ?
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