Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

ESR On XML-RPC

Hemos posted more than 13 years ago | from the good-take-on-things dept.

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

cancel ×

154 comments

Sorry! There are no comments related to the filter you selected.

Joy or ESR? (2)

Karpe (1147) | more than 13 years ago | (#416076)

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

Re:Why isn't XML-RPC considered bloat? (2)

rongen (103161) | more than 13 years ago | (#416080)

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

It isn't just bandwidth (1)

Carnage4Life (106069) | more than 13 years ago | (#416082)

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

Re:A question about DCOP (2)

Karma Sucks (127136) | more than 13 years ago | (#416084)

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

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

You can do so much scripting with this information

dcop kwrite KWriteIface
QCStringList interfaces()
QCStringList functions()
void cursorLeft()
void shiftCursorLeft()
void cursorRight()
void shiftCursorRight()
void wordLeft()
void shiftWordLeft()
void wordRight()
void shiftWordRight()
void home()
void shiftHome()
void end()
void shiftEnd()
void up()
void shiftUp()
void down()
void shiftDown()
void scrollUp()
void scrollDown()
void topOfView()
void bottomOfView()
void pageUp()
void shiftPageUp()
void pageDown()
void shiftPageDown()
void top()
void shiftTop()
void bottom()
void shiftBottom()
int numLines()
QString text()
QString currentTextLine()
QString textLine(int num)
QString currentWord()
QString word(int x,int y)
void insertText(QString txt,bool mark)
void setCursorPosition(int line,int col,bool mark)
bool isOverwriteMode()
void setOverwriteMode(bool b)
int currentLine()
int currentColumn()
bool loadFile(QString name,int flags)
bool writeFile(QString name)

Re:Is ESR Relevant? (1)

Arandir (19206) | more than 13 years ago | (#416087)

I can't remember the name, but a block north of Shoreline on El Camino there is a good place that serves up Gyros

An interesting point in an (2)

jjr (6873) | more than 13 years ago | (#416088)

Another article [userland.com] 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

Re:Is ESR Relevant? (2)

Jon Erikson (198204) | more than 13 years ago | (#416089)

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... (1)

Darth Yoshi (91228) | more than 13 years ago | (#416090)

The XML-RPC HOWTO is here [sourceforge.net] .

Re:Is ESR Relevant? (1)

KidSock (150684) | more than 13 years ago | (#416094)


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:It isn't just bandwidth (1)

Phillip Birmingham (2066) | more than 13 years ago | (#416096)

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

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

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

Re:Why isn't XML-RPC considered bloat? (1)

tauzell (25739) | more than 13 years ago | (#416097)

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.

SOAP (1)

tedd (30053) | more than 13 years ago | (#416100)

How does this compare to Microsoft's SOAP (Simple Object Access Protocol) [microsoft.com] ?

see http://msdn.microsoft.com/xml/general/soapspec.asp

ted

Re:A simple and clear concept -- WAY offtopic!!!!! (1)

$eyeB0rq_munqee (313802) | more than 13 years ago | (#416102)

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

Re:Another case of too little, too late? (1)

Erv Walter (474) | more than 13 years ago | (#416103)

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.

XML (2)

SquadBoy (167263) | more than 13 years ago | (#416104)

is there anything it can't do?

Re:Why isn't XML-RPC considered bloat? (1)

FredNerk (121006) | more than 13 years ago | (#416106)

Yes. It's true that as a consequence of its text-based nature, communication via XML is decidedly more bandwidth-intensive than any binary counterpart. The problem, though, lies in translation of that binary format two and from different machines, architectures, languages, and implementations.

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

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

A simple and clear concept (1)

Shoeboy (16224) | more than 13 years ago | (#416107)

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

Re:Underspecification invites Security Risks (1)

aburns (223872) | more than 13 years ago | (#416108)

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.

Re:so whiner just signed up (1)

Phillip Birmingham (2066) | more than 13 years ago | (#416109)

At least he signed up© Loser©

Another case of too little, too late? (2)

Jon Erikson (198204) | more than 13 years ago | (#416110)

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. (4)

Wesley Felter (138342) | more than 13 years ago | (#416111)

There are several XML compression formats out there already; it's too bad people haven't decided on one, though.

Fun stuff (2)

Anonymous Coward | more than 13 years ago | (#416112)

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 ;)

Forget SOAP and XML-RPC (1)

MeowMeow Jones (233640) | more than 13 years ago | (#416113)

If you really want to use XML and Distributed Components in an even less practical way, check this out. [microsoft.com]

Re:Is ESR Relevant? (3)

update() (217397) | more than 13 years ago | (#416114)

For me, he stopped having credibility shortly after the flurry of Linux-related IPOs.

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

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

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

Re:Its time for: WHAT IS ESR WORTH? (2)

SoftwareJanitor (15983) | more than 13 years ago | (#416119)

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

Re:It isn't just bandwidth (1)

aminorex (141494) | more than 13 years ago | (#416120)

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

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

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

Re:Is ESR Relevant? (2)

khaladan (445) | more than 13 years ago | (#416123)

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.

Re:In action yes...but gives lip-service to BSD (1)

mr (88570) | more than 13 years ago | (#416125)

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?

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/ 4. x-STABLE/packages/mail/fetchmail-5.6.5.tgz
where you change the 4.x-STABLE depending on the system you have.

Re:A simple and clear concept -- WAY offtopic!!!!! (1)

Tonetheman (173530) | more than 13 years ago | (#416127)

Irregardless is not a word...

Re:Interesting. (OT) (1)

doozy (20820) | more than 13 years ago | (#416129)

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

Re:What about CORBA? (2)

Trepalium (109107) | more than 13 years ago | (#416130)

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

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

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

Re:Another case of too little, too late? (1)

Trepalium (109107) | more than 13 years ago | (#416131)

... microsoft ... put SOAP and XML into the w2k kernal...
Hardly, SOAP and XML may be part of the core SDK and install, but they're hardly part of the kernel in Windows 2000. And indeed a text parser would be stupid to put in kernel space, even for Microsoft. The gains in performance would be so minor to be worthless, whereas the loss in security and stability would undermine Microsoft's efforts to inspire confidence in Windows 2000's stability. Microsoft might've done some stupid things in it's lifetime, but putting something like this in kernel space is definately not one of them. SOAP in Win2K is handled by by IIS for the server and a couple DLLs for the client.

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

Again, this would be stupid. Such code should never run in the kernel's context, because crashes there, are fatal. However, I would like to see XML-RPC and/or SOAP becoming part of standard linux distribution, if for no other reason than to encourage interoperability between platforms (and not just POSIX-like platforms).

Re:Is ESR Relevant? (2)

sv0f (197289) | more than 13 years ago | (#416132)

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.

HTTP supports this (2)

MeowMeow Jones (233640) | more than 13 years ago | (#416133)

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.

More comments... (2)

wdavies (163941) | more than 13 years ago | (#416134)

In the example

<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 /WINTON HTTP/1.0
...
<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:Interesting. (1)

348 (124012) | more than 13 years ago | (#416135)

It is good to hear ESR's views on this subject too - he is an articulate and interesting writer.

Suck up. LOL

Proprietary? (1)

Improv (2467) | more than 13 years ago | (#416136)

Why do you think of it as being proprietary
and not 'truly open'? Are you confusing
ubitquousness for openness?

Re:Is ESR Relevant? (1)

Skyshadow (508) | more than 13 years ago | (#416137)

Thanks, man. This craving has been killing be for like three weeks now.

----

Re:.xml, meet .rar (2)

MrBogus (173033) | more than 13 years ago | (#416138)

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.

Re:Is ESR Relevant? (3)

blair1q (305137) | more than 13 years ago | (#416150)

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

Re:Is ESR Relevant? (2)

judd (3212) | more than 13 years ago | (#416151)

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.

FYI KDE has built in support for XML-RPC (4)

Rich (9681) | more than 13 years ago | (#416152)

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.

Re:Is ESR Relevant? (5)

Ross C. Brackett (5878) | more than 13 years ago | (#416153)

How about this:
$less /etc/termcap

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

Re:RPC is OLD. XML is LAME. Why waste time ? (1)

Lord of Caustic Soda (3117) | more than 13 years ago | (#416154)

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.

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 /proc in XML in Linux kernel?!).

Re:Is ESR Relevant? (1)

oops (41598) | more than 13 years ago | (#416155)

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 [tuxedo.org] to take his rants seriously. Or perhaps I'm too British :-)

Now this is irony... (1)

BitwizeGHC (145393) | more than 13 years ago | (#416156)

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

The joys of hardware (2)

SuiteSisterMary (123932) | more than 13 years ago | (#416157)

Don't forget the hardware XML accelerators [intel.com] for just such occasions.

Speed issues? Portability issues? (1)

Frank T. Lofaro Jr. (142215) | more than 13 years ago | (#416158)

Am I the only one who thinks doing XML RPC could end up being slow? XML isn't lightweight. What are the performance considerations? XML is also very free form. How will you understand XML I send you? Could it be like everyone around the world using the same grammer when speaking, but different words? (which would still prevent people from understanding each other)

Not a flame, just a question.

What about CORBA? (2)

vt0asta (16536) | more than 13 years ago | (#416159)

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.

Re:Is ESR Relevant? (1)

look (36902) | more than 13 years ago | (#416160)

Not to mention the way he's unabashedly biased the Jargon File. Check out the entry for Python [tuxedo.org] , 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.

Re:Joy or ESR? (2)

TWR (16835) | more than 13 years ago | (#416166)

And this is willful misunderstanding of what Bill Joy is talking about.

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

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

-jon

Re:.xml, meet .rar (1)

Lord of Caustic Soda (3117) | more than 13 years ago | (#416167)

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?

XMLRPC vs SOAP (4)

Leghk (30302) | more than 13 years ago | (#416168)

We use XMLRPC in one of our enterprise-(ish) applications for webbased API calls. Works very well. As for SOAP, SOAP more or less does the same thing; except it's more of an "enterprise" solution. Microsoft is one of the big bangers behind SOAP, and numerous other large companies such as IBM (and sun, sorta).

The problem with SOAP, is it's not really done, and it doesn't really work. So we decided to go with XMLRPC (because it works), and eventually replace it with SOAP once the standard stabilizes and there's actual functional implementations.

One example of XMLRPC not being quite ready for prime-time, is it's lack of Null support. As the article described XMLRPC allows the passing of primitives and some complex datastructures nativly (strings, lists, hashes, ints), but it does not support passing nulls. Anybody whose tried to use XMLRPC will spend about an hour scratching their head when they program an XMLRPC call which (in java or C) has a return type of void (such as a setter for a variable). XMLRPC will choke because it can't describe a Null. So you end up having to return blank strings to work around the problem.

You know some XMLRPC specifications guy just slapped his head when he read this saying, "dammit, I knew I forgot something!".

In action yes...but gives lip-service to BSD (2)

mr (88570) | more than 13 years ago | (#416169)

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.

Slow..... (2)

be-fan (61476) | more than 13 years ago | (#416170)

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?

Is Skyshadow still Relevent? (was) Re: is ESR R... (2)

DeathBunny (24311) | more than 13 years ago | (#416171)

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

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

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

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

My experiencie implementing XML-RPC (3)

Nicopa (87617) | more than 13 years ago | (#416172)

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.

Re:Is ESR Relevant? (1)

Flabdabb Hubbard (264583) | more than 13 years ago | (#416173)

I have to admit, I had not heard of ESR as an Open Source hero, but I think he wrote the highly useful "procmail". While not wishing to take anything away from this effort, Its worth pointing out that this is dwarfed by RMS's efforts.

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 ?

ESR never was relevant... (2)

alexhmit01 (104757) | more than 13 years ago | (#416174)

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

Why isn't XML-RPC considered bloat? (3)

Carnage4Life (106069) | more than 13 years ago | (#416175)

I am a big fan of distributed computing, heck I wrote an article about it on K5 [kuro5hin.org] , 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

Re:Is ESR Relevant? (5)

Tony Shepps (333) | more than 13 years ago | (#416176)

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?

XML-RPC enodrsed by Vatican? (1)

MSBob (307239) | more than 13 years ago | (#416177)

I went to XML-RPC [xmlrpc.org] 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!

Interesting. (4)

Heidi Wall (317302) | more than 13 years ago | (#416178)

I had not heard of XML-RPC until a few months ago, but I found XML-RPC for Newbies [userland.com] to be an extremely useful site allowing me to get up to speed on an interesting subject.

It is good to hear ESR's views on this subject too - he is an articulate and interesting writer.
--
Clarity does not require the absence of impurities,

Is ESR Relevant? (3)

Skyshadow (508) | more than 13 years ago | (#416179)

Accomplishments from the fetchmail project aside, does anyone think that ESR still has a credible voice in the community? For me, he stopped having credibility shortly after the flurry of Linux-related IPOs. I, along with a lot of other people, interpreted his statements as arrogant, thinly-guised, and frankly insulting bragging (the exact stuff we love Linus for *not* doing).

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

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

----

Re:SOAP (4)

Philbert Desenex (219355) | more than 13 years ago | (#416180)

As I understand it, SOAP evolved from XML-RPC. See: http://www.develop.com/soap/soapfaq.htm#22 for a hint at history and ancestry.

I'm of a mixed mind about both SOAP and XML-RPC. XML-RPC includes explict typing of passed values, and SOAP does not. Point to XML-RPC. XML-RPC is substantially simpler than SOAP. Point to XML-RPC.

I bet SOAP wins, because it's heinously complicated. Big companies and big devel shops love complicated: it raises the cost of entry into a market where the complicated standard prevails.

Re:Another case of too little, too late? (2)

William Tanksley (1752) | more than 13 years ago | (#416182)

Well, as I recall, XML-RPC was the origin of SOAP. So hopefully SOAP will replace it, but that just means that XML-RPC did its job well.

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

-Billy

Re:A simple and clear concept -- WAY offtopic!!!!! (1)

bluelip (123578) | more than 13 years ago | (#416185)

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?)


Re:ESR likes SOAP (1)

Bowie J. Paog (229002) | more than 13 years ago | (#416186)

What are you talking about?
ESR has never seen a bar of soap.

Bowie J. Poag

XML RPC and CORBA (3)

darrint (265374) | more than 13 years ago | (#416191)

I've long thought that ideas such as XML RPC need to be somehow connected with the CORBA world.

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

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

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

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

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

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

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

Re:RPC is OLD. XML is LAME. Why waste time ? (1)

Flabdabb Hubbard (264583) | more than 13 years ago | (#416192)

You have to redeploy all your clients every time an insignificant argument changes

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.

XML-RPC, SOAP, and the Rest... (2)

edashofy (265252) | more than 13 years ago | (#416193)

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!

Re:Is ESR Relevant? (3)

AMK (3114) | more than 13 years ago | (#416194)

See recent python-dev summaries for what ESR is up to. Such as this one [www.amk.ca] (adding string methods) and this one [www.amk.ca] (speculating about Tk's fate).

Re:RPC is OLD. XML is LAME. Why waste time ? (1)

distobj (32824) | more than 13 years ago | (#416195)

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.

No, he deserves it... (1)

lwagner (230491) | more than 13 years ago | (#416196)

Granted, most of the "shakers" in 1999 and 2000 were loud and obnoxious, but he pretty much brought it upon himself and tried to roll as a hacker and a power-broker.

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.

--

Aye, he be a choad-monger (1)

Anonymous Coward | more than 13 years ago | (#416197)

The proof be here [amazon.com] .

All these posts, and no Winerlog? (1)

Anonymous Coward | more than 13 years ago | (#416198)

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 [editthispage.com] . Yadda!

Re:Another case of too little, too late? (3)

Flabdabb Hubbard (264583) | more than 13 years ago | (#416199)

Well, I have to agree, Since microsoft have effectively done the right thing, and put SOAP and XML into the w2k kernal, it is easy to see why SOAP will win in the marketplace.

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

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

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

Remember... (1)

aburns (223872) | more than 13 years ago | (#416200)

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?

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 .com survive the fallout and what more can you say.

Rember pick the right tool and the job is immensly easier.

WHAT IS ESR WORTH (1)

Ars-Fartsica (166957) | more than 13 years ago | (#416201)

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.

A question about DCOP (2)

Wesley Felter (138342) | more than 13 years ago | (#416202)

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.

What's wrong with good ol' RPC? (2)

ChrisWong (17493) | more than 13 years ago | (#416203)

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

Re:SOAP (1)

Sam Ruby (8995) | more than 13 years ago | (#416204)

It isn't just Microsoft's SOAP. There is an Apache implementation here [apache.org] . The spec has also been accepted by the w3c, and renamed to XP [w3.org]

Re:Another case of too little, too late? (5)

daveuserland (315086) | more than 13 years ago | (#416205)

XML-RPC predates SOAP by a few years, and has more implementations, and has demostrated interop. SOAP, which I am also a co-author and supporter of, has not yet reached substantial interop, and this is going to be a bit difficult, but we'll get there. You're right that SOAP has more support from large companies, and that's great, but as an independent developer who doesn't want to be controlled by the large companies, I think XML-RPC provides a valuable insurance policy. I'm very happy to get ESR's endorsement of XML-RPC.

Re:Is ESR Relevant? (4)

4of12 (97621) | more than 13 years ago | (#416206)

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? (5)

miracle69 (34841) | more than 13 years ago | (#416207)

Saw this over on LinuxToday.

Zoom over to Google and put in Eric Raymond (or just check this link [google.com] out). Notice the paid hotlink...

.xml, meet .rar (3)

cryptochrome (303529) | more than 13 years ago | (#416208)

XML was designed to transfer data between programs and across platforms. The cross-platform clarity and reliability is great, but an XML file is really bloated relative to a specific file format, which is hardly conducive to transfering files.

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

cryptochrome

Re:A simple and clear concept -- WAY offtopic!!!!! (1)

Ig0r (154739) | more than 13 years ago | (#416209)

He's obviously satirizing the infamous and quite moronic posts of "Lover's Arrival, The".

--

Re:Another case of too little, too late? (2)

1010011010 (53039) | more than 13 years ago | (#416213)

Uhhh... XML parsing in the kernel? Really?

- - - - -

To Dave Winer and Eric Raymond (2)

Karma Sucks (127136) | more than 13 years ago | (#416215)

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)

Re:In action yes...but gives lip-service to BSD (2)

scrytch (9198) | more than 13 years ago | (#416217)

> Fetchmail has no pre-done BSD binaries

Because it builds out of the box. If you insist on binaries, then I present for your downloading pleasure, ftp://ftp.freebsd.org/pub/FreeBSD/branches/-curren t/ports/mail/fetchmail.tar

which has been there all along.
--

Re:Joy or ESR? (1)

Karpe (1147) | more than 13 years ago | (#416218)

Not talking about SOAP. Read his interview published here some days ago.

Re:Why isn't XML-RPC considered bloat? (4)

Hrunting (2191) | more than 13 years ago | (#416220)

Anyone see any errors in this thinking?

Yes. It's true that as a consequence of its text-based nature, communication via XML is decidedly more bandwidth-intensive than any binary counterpart. The problem, though, lies in translation of that binary format two and from different machines, architectures, languages, and implementations.

I currently do quite a bit of work using SOAP, which is similar to XML-RPC, but a little less well-developed. It's a no-brainer. If I'm using Java, Perl, C, C++ or even Python, it's relatively easy to make calls between these different languages. I don't have to worry about the endianess of the data I'm working with. I don't have to worry about learning some new data encoding scheme (XML is very well-defined, and very ubiquitous; almost every language has a translator). Communicating between a language like Perl, which has no typing, and Java, which has more strict typing is a no brainer, because the data structures are defined by a well-documented, human readable schema, and when I look at the data I'm sending, I can see the raw information.

Bandwidth concerns might have been paramount two years ago, but the world in which XML-RPC and SOAP are being used has already shifted to broadband. Now, human clarity and complete interoperability, as well as the ease of use of porting XML-RPC (or SOAP) constructs to another language (since it's just XML text) make it a much more efficient model in terms of programmer time.

Yes, from a strictly bandwidth concern, CORBA or DCOM beat XML hands down, but when you remove that consideration, it's not that big a deal. Couple it with existing protocols (I've seen SOAP implementations via HTTP, FTP, and even SMTP), and the opportunity to grow via existing infrastructure and well-known technologies, and you just have an easier (and thus, I would argue, more open) model to work with.

Re:Is ESR Relevant? (2)

SubtleNuance (184325) | more than 13 years ago | (#416222)

does anyone think that ESR still has a credible voice in the community

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

Sorry.

Underspecification invites Security Risks (4)

billstewart (78916) | more than 13 years ago | (#416223)

I'm just starting to buckle down and learn XML, so I may have the occasional detail wrong and major clue missing, but I've got several decades of experience with bad security and inadequate design :-)


The biggest technical security risk in most environments is that Bad Guys can hand programs input that doesn't have the properties that the programs' authors expected, and in networked environments (such as an RPC) there are Bad Guys all over the Solar System who have the means of handing input to your programs (both client and server), and RPC mechanisms have been a popular target for crackers, not that networking in general isn't a target-rich environment. Anybody who provides a new general RPC mechanism and doesn't make the default behavior to be "secure" at least to the extent of safety-checking input is a danger to the community. I don't see any evidence that XML-RPC addresses this problem.


The great thing about XML, besides flexibility and popularity, is that it provides a mechanism for defining valid input, through the use of Document Type Definitions, so parsers can determine whether input is both well-formed and valid. That doesn't mean that everybody writing a program that uses your XML DTD will write it safely, or even if they use a parser that they'll refrain from mismanaging memory, but at least they'll all have a consistent spec for what they need to support, and if they've got an xml parser that they're using, it'll have something to work from.
The XML-RPC Spec [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 (2)

Karma Sucks (127136) | more than 13 years ago | (#416224)

Shell script is easier for some folks:

# 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/ //g'`

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

EOF

( echo open localhost $port
sleep 2
cat head.xml cmd.xml
sleep 2
) | telnet -8E

RPC is OLD. XML is LAME. Why waste time ? (1)

Flabdabb Hubbard (264583) | more than 13 years ago | (#416225)

Lets face it, RPC has been done to death. Jesus, it was old in 1991 when I did my masters, it is positivly rotting in the grave now. What about causally-ordered multicast (like the ISIS system) or Tuple spaces like Dave Gelernters Linda system. RPC is an INADEQUATE model for distributed systems, and is holding us back.

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 ?

Re:Is ESR Relevant? (1)

flayum (64108) | more than 13 years ago | (#416226)

Of course he is relevant, but not quite as relevant as he used to be. I still like to hear what he has to say, as long as he's not flaming someone and not bragging.

XML-RPC and Python (3)

f3e2 (235629) | more than 13 years ago | (#416227)

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? (5)

Goonie (8651) | more than 13 years ago | (#416228)

ESR's thoughts *are* worth considering. He still does real coding (for instance, he's currently working on replacing the Linux kernel configuration system with something considerably better, from all accounts), and he is a thoughtful and incisive writer - lets not discount the value that many of his writings have had.

Yes, he has a big ego which he's not afraid to let show (at least in his writing, he may be a wallflower in person for all I know), but so do a lot of other people who have done considerably less than he has.

Sure, don't treat the guy as some kind of god, but don't ignore him just because he's not the flavour of the month any more.

Re:Is ESR Relevant? (1)

Floyd Tante (210193) | more than 13 years ago | (#416229)

Accomplishments from the fetchmail project aside,

Hey, don't forget the broken version of ncurses he released (3.something). Fortunately, more able people have since released a better version [gnu.org] .

does anyone think that ESR still has a credible voice in the community? For me, he stopped having credibility shortly after the flurry of Linux-related IPOs.

You mean when he wrote self-promoting crap like his "Newfound Wealth" [slashdot.org] bitching-cause-i'm-rich or the "Take my Job please" [tuxedo.org] bitching-cause-i'm-famous bit?

I, along with a lot of other people, interpreted his statements as arrogant, thinly-guised, and frankly insulting bragging (the exact stuff we love Linus for *not* doing).

You're hardly the only one.

In any event, it seems to me that his role as a community mouthpiece has been largely taken over

It's about time.

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

Not hardly. If a tree fell on ESR in a forest filled with Linux users, would anyone notice? The guy is, and always has been, all talk. Say what you will about RMS (a communist), Larry Wall (a pseudo-scientist babbler), or Theo deRaadt (a sociopathic cult leader), but they produce working code. Until ESR does more than a simple mail downloader (is he capable of it?), he is simply not needed.

(I already know what the trolls think),

Heh.

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?

One word: no.


-- Floyd
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>