Skip to main content

Timeline for answer to What is the benefit of XML-RPC over plain XML? by ChssPly76

Current License: CC BY-SA 2.5

Post Revisions

9 events
when toggle format what by license comment
Aug 18, 2010 at 11:05 comment added analytik I agree with Warren. I've checked 10 links, some of them were dead, the others were from 2002-2004.
Sep 4, 2009 at 17:38 comment added ChssPly76 @Tim - I'm not sure how to explain this any clearer. Here's something that might help - write a schema (or DTD) for your 'ROOM' xml; make sure it validates. Toss in an "arbitrarily complex tree" while you're at it; don't forget method calls / results / exception mapping (this is RPC after all). Now, do the same thing for 'CAR' entity ('STOCK_TRADE', 'MEDICAL_RECORD', anything) - keep in mind that all your new XML mappings must conform to that same schema / DTD you've created. Now compare that schema to XML-RPC spec.
Sep 4, 2009 at 13:32 comment added Warren Young Re your "quite ubiquitous" link, that's a good example of the waning interest in -- or at least lack of growth of -- XML-RPC. At least one of the links on that page points to a domain squatter's site, even though I sent the site maintainer an update 5 weeks ago. The most recent message on the mailing list is even older, and there are several other broken links on that site, some of them top-level links. Yes, I'm conflating Dave Winer's waning interest with the community's. Communities need leaders, and weak leadership means weak communities. Maybe JSON will take over from XML-RPC...
Sep 4, 2009 at 13:01 comment added Tim Cooper XML has the ability to represent arbitrarily complex trees - I didn't get your point about "inability to convey anything but simple structure". Data types seems to be the only thing that XmlRpc adds...(although there is often a mismatch between type systems anyway between different languages.) In any XmlRpc-based protocol, there needs to be some common understanding of the object structure, e.g. what field names to expect, but XML and XmlRpc both let you add fields and reorder fields without affecting semantics. XML must be adequate for real-life communication because it's used quite widely.
Sep 4, 2009 at 3:19 comment added ChssPly76 Both your XML one-liner and my pipe-separated string can successfully be used for communication between two parties. In both cases the receiving party must ALREADY know the object structure (your XML lacks data types, for example, not to mention its inability to convey anything but simple structure in its present form); and if I do know what I'm unmarshalling I don't really need field names. The point is - your XML examples are inadequate for real-life communication whereas XML-RPC is.
Sep 4, 2009 at 3:11 comment added Tim Cooper I don't understand the point about relying on field order. In this case, the attributes (or tags) have names. Why wouldn't you look at the field names rather than the field order?
Sep 4, 2009 at 1:36 comment added ChssPly76 You're wrong. Taking your example, <room ROOM_ID=1 CODE=MR-101 NAME=”Math Room” CAPACITY=30 /> how would I know how to unmarshall that into an object if I were to receive this over a wire? It's no different from getting, say, room|1|MR-101|Math Room|30 and relying on field order. The point is, XML-RPC provides a well defined communication protocol - XML by itself does not.
Sep 4, 2009 at 1:12 comment added Tim Cooper 3) If I was to make remote procedure calls with plain strings or binary, this would be horrible and require designing formats for each interaction. But plain XML gives a well defined format for passing structured values. I don't think you've answered the question "what does XmlRpc have over XML?" 1) My examples compare XmlRpc with XML, and prove that you don't need to be verbose to be interoperable. XML is considered a protocol which is good for interoperability.
Sep 4, 2009 at 0:45 history answered ChssPly76 CC BY-SA 2.5