ESR On XML-RPC 154
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.""
Joy or ESR? (Score:2)
Re:Underspecification invites Security Risks (Score:1)
Rich.
Re:.xml, meet .rar (Score:2)
Re:Bruce Perens practical joke on Eric Raymond? (Score:1)
Re:Why isn't XML-RPC considered bloat? (Score:2)
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 [xml-rpc.com]!
--8<--
Re:SOAP (Score:1)
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.
It isn't just bandwidth (Score:1)
The advantage of distributed object systems like CORBA, DCOM or RMI over XML-RPC is a lot more than bandwidth. The problem is that distributed computing faces a lot of issues like transactional behavior, security, robust error recovery, object persistence plus a bunch of other issues that involvetracking state across sessions and I'm not sure how throwing in a bloated protocol into this mish mash is truly beneficial.
Now if it's just comparing regular RPC to XML_RPC then it can still be argued that adding the bloat of XML-RPC so that calls can work across systems or languages is not worth it considering how rarely real cross platform distributed computing is done.
Finagle's First Law
Irregardless (Score:1)
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.
Re:A question about DCOP (Score:2)
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)
Re:What about CORBA? (Score:1)
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.
Re:Hey I am also gay! Have a problem with it? (Score:1)
Re:Is ESR Relevant? (Score:1)
An interesting point in an (Score:2)
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
Re:Is ESR Relevant? (Score:2)
You say he still does real coding, and yet when was the last time we saw anything from him? Like RMS he seems to have become famous whilst only having produced a single piece of well-known code, but at least RMS has something he believes in.
ESR seems to have recently decided that the best interests of Open Source lies in bending over and taking it from as many corporate CTOs as possible. Rather than actually getting down and doing anything (other than maintaining the pointless Jargon File) he spends most of his time either talking to suits or writing his usual arrogant drivel.
ESR is just one cog who got a lucky break and tried to play it for all he was worth. He deserves no more attention than any other open source coder.
The XML-RPC HOWTO is here... (Score:1)
Re:Another case of too little, too late? (Score:1)
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.
Great ESR Wisdom (Score:2)
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.
Re:Is ESR Relevant? (Score:1)
What the heck you talking about? Or you just trolling through?
Re:Is ESR Relevant? (Score:1)
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?
Re:XML-RPC -- great concept, execution needs help (Score:1)
Re:It isn't just bandwidth (Score:1)
Maybe it's not done because it's been so hard up till now© Maybe nothing good will come out of it, but I can't help but be excited, because a great many things will move from the realm of the possible, into the realm of the easy©
In any case, it's now a hell of a lot easier to see what those remote calls are callin' for© That's got to be worth something in the debug cycle©
Re:Why isn't XML-RPC considered bloat? (Score:1)
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.
true (Score:1)
Meerkat and Zope (Score:2)
--
SOAP (Score:1)
see http://msdn.microsoft.com/xml/general/soapspec.asp
ted
Re:Why isn't XML-RPC considered bloat? (Score:1)
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.
Re:A simple and clear concept -- WAY offtopic!!!!! (Score:1)
Re:Another case of too little, too late? (Score:1)
XML (Score:2)
Re:SOAP (Score:2)
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.
Re:Why isn't XML-RPC considered bloat? (Score:1)
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.
A simple and clear concept (Score:1)
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
Re:Underspecification invites Security Risks (Score:1)
Re:so whiner just signed up (Score:1)
Another case of too little, too late? (Score:2)
I wonder what these people think about SOAP [w3.org]?
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.
WBXML, XMill, etc. (Score:4)
Fun stuff (Score:2)
Forget SOAP and XML-RPC (Score:1)
Re:Is ESR Relevant? (Score:3)
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"....
Re:Hey I am also gay! Have a problem with it? (Score:1)
how fitting!
Re:XML RPC and CORBA (Score:1)
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
no question it's better to use a database, but... (Score:2)
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
Plain RPC is Unix-ish too (Score:1)
Re:Its time for: WHAT IS ESR WORTH? (Score:2)
Next troll...
Re:It isn't just bandwidth (Score:1)
Stuff like error recovery, object persistence, etc., belongs at higher levels of an application stack, not at the request/response level.
When an application's native format is XML, XML RPC is much easier to use than a binary format. When I persist to XML, and need to pump an object over the wire, I can just sendfile() and be done with it.
Re:RPC is OLD. XML is LAME. Why waste time ? (Score:1)
And is there proof that XML is going to be easier to program for than any other data structure?
Re:What about CORBA? (Score:1)
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.
Re:Is ESR Relevant? (Score:2)
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.
Re:In action yes...but gives lip-service to BSD (Score:1)
Um, might that be because BSD ports are usually supported by someone other than the author of the software?
Re:What about CORBA? (Score:2)
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.
Re:Is ESR Relevant? (Score:2)
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.
HTTP supports this (Score:2)
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.
More comments... (Score:2)
<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
Re:.xml, meet .rar (Score:2)
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.
RMS and ESR accomplishments. (Score:2)
> 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.
Re:Bruce Perens practical joke on Eric Raymond? (Score:2)
Bruce
Re:Is ESR Relevant? (Score:3)
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 [tuxedo.org]. 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.
Re:A question about DCOP (Score:2)
Re:Is ESR Relevant? (Score:3)
After that, anything he has to say about communal efforts is the height of hypocrisy.
--Blair
Re:Is ESR Relevant? (Score:2)
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.
FYI KDE has built in support for XML-RPC (Score:4)
Rich.
Comment removed (Score:5)
The joys of hardware (Score:2)
What about CORBA? (Score:2)
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.
XML-RPC -- great concept, execution needs help (Score:4)
Re:Joy or ESR? (Score:2)
XML is being pushed by various yahoos as a way to achieve cross-platform compatibility. It doesn't. It provides a way to exchange data in a standard format, but nothing else. You still need some code to process the XML, and it is ideal for that code to be cross-platform to prevent vendor lock-in.
If you think that XML (or XML-RPC) alone is sufficient, please show me an XML parser written in XML. All the non-fanboys will clearly understand why this is a silly statement.
-jon
XMLRPC vs SOAP (Score:4)
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 yes...but gives lip-service to BSD (Score:2)
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.
Slow..... (Score:2)
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?
Is Skyshadow still Relevent? (was) Re: is ESR R... (Score:2)
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?
My experiencie implementing XML-RPC (Score:3)
This is my experience with XML-RPC:
I work for a company (Technisys [technisys.com.ar]) 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 [xmlsoft.org] 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 [helma.at] 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.
ESR never was relevant... (Score:2)
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
Why isn't XML-RPC considered bloat? (Score:3)
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
Re:Is ESR Relevant? (Score:5)
Interesting. (Score:4)
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,
Is ESR Relevant? (Score:3)
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?
----
Re:SOAP (Score:4)
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.
Re:Another case of too little, too late? (Score:2)
Actually, I hope that XML-RPC will wind up being a proper subset of SOAP. That would be convenient.
-Billy
Worse is Better (Score:2)
--
XML RPC and CORBA (Score:3)
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.
XML-RPC, SOAP, and the Rest... (Score:2)
Re:Is ESR Relevant? (Score:3)
Re:Another case of too little, too late? (Score:3)
Of course I realise this is slashdot, and pandering to the marketroids is tantamount to heresy, but it needs to be said.
For this XML-RPC effort to succeed, it needs to be implemented as a kernel-loadable module, and be included in the default Linux kernal.
Then and only then will Linux be fully riding the XML bandwagon
A question about DCOP (Score:2)
What's wrong with good ol' RPC? (Score:2)
Re:Another case of too little, too late? (Score:5)
Re:Is ESR Relevant? (Score:4)
Yes.
ESR's coding contributions have some genuine measure of usefulness. He sweats details (like little bugs, documentation) that other open source projects gloss over.
His philosophy is also interesting and insightful. The problem, of course, that whatever amount of insight and creativity he has is finite and becomes wearily diluted when hyped in the media. The same problem would afflict any "visionary" the media happens to glorify.
Regarding XML-RPC, I figure SOAP has become the next incarnation for better or worse. I've heard it's got chrome tailfins, but the same essential useful concept under the hood.
Bruce Perens practical joke on Eric Raymond? (Score:5)
Zoom over to Google and put in Eric Raymond (or just check this link [google.com] out). Notice the paid hotlink...
.xml, meet .rar (Score:3)
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
XML-RPC *is* Unix-ish (Score:2)
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 [sourceforge.net], 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 [perl.org] 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.
Re:XMLRPC vs SOAP (Score:2)
XMLRPC
- has a really small amount of tags
- is really easy to use (straightforward)
- libs are available for nearly every flavour of prgramming language
- specs are there and seemingly final
- lot of programs support it, there are even small cmd-line and gui test programs
SOAP
- has been passed on to the w3c
- since then it has "evolved" and "evolved" and "evolved"
- no final spec yet
- no date for the spec yet to see
- horrendous ammount of tags
- not as straight forward as XMLRPC (at least to me)
- nearly no support in libs or programs
Anyway I used XMLRPC to connect java, visal basic an zope
BTW: there are (at least) three more protocols out there that no one has looked at yet
Re:Another case of too little, too late? (Score:2)
- - - - -
To Dave Winer and Eric Raymond (Score:2)
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)
Re:In action yes...but gives lip-service to BSD (Score:2)
Because it builds out of the box. If you insist on binaries, then I present for your downloading pleasure, ftp://ftp.freebsd.org/pub/FreeBSD/branches/-curre
which has been there all along.
--
Re:Why isn't XML-RPC considered bloat? (Score:4)
Yes. It's true that as a consequence of its text-based nature, communication via XML is decidedly more bandwidth-intensive than any binary counterpart. The problem, though, lies in translation of that binary format two and from different machines, architectures, languages, and implementations.
I currently do quite a bit of work using SOAP, which is similar to XML-RPC, but a little less well-developed. It's a no-brainer. If I'm using Java, Perl, C, C++ or even Python, it's relatively easy to make calls between these different languages. I don't have to worry about the endianess of the data I'm working with. I don't have to worry about learning some new data encoding scheme (XML is very well-defined, and very ubiquitous; almost every language has a translator). Communicating between a language like Perl, which has no typing, and Java, which has more strict typing is a no brainer, because the data structures are defined by a well-documented, human readable schema, and when I look at the data I'm sending, I can see the raw information.
Bandwidth concerns might have been paramount two years ago, but the world in which XML-RPC and SOAP are being used has already shifted to broadband. Now, human clarity and complete interoperability, as well as the ease of use of porting XML-RPC (or SOAP) constructs to another language (since it's just XML text) make it a much more efficient model in terms of programmer time.
Yes, from a strictly bandwidth concern, CORBA or DCOM beat XML hands down, but when you remove that consideration, it's not that big a deal. Couple it with existing protocols (I've seen SOAP implementations via HTTP, FTP, and even SMTP), and the opportunity to grow via existing infrastructure and well-known technologies, and you just have an easier (and thus, I would argue, more open) model to work with.
Re:Is ESR Relevant? (Score:2)
I am no more a member of the community than anyone else - *BUT* - I support virtually everything Ive read that ESR has written.
Sorry.
Underspecification invites Security Risks (Score:4)
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 [xmlrpc.com] 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.
even better code (Score:2)
# 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
XML-RPC and Python (Score:3)
We use XML-RPC on our Python [python.org]-powered intranet to grab headlines from O'Reilly's free Meerkat wire service [oreillynet.com] via Secret Lab's free xmlrpclib [secretlabs.com] module. Dave Warner wrote an excellent article on XML-RPC and Python here [oreillynet.com], 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 [oreillynet.com], with sample PHP and Perl code (as well as Python).
-M
You're smart; why haven't you learned Python yet? diveintopython.org [diveintopython.org]
Re:Is ESR Relevant? (Score:5)
Yes, he has a big ego which he's not afraid to let show (at least in his writing, he may be a wallflower in person for all I know), but so do a lot of other people who have done considerably less than he has.
Sure, don't treat the guy as some kind of god, but don't ignore him just because he's not the flavour of the month any more.