REST could take advantage of this work and still keep its purity, by using the serialization format. I've been saying that for a very long time. Anyway, now I'm thinking about coming up with a successor to XML-RPC, that takes into account all that we now know, and perhaps integrating with OAuth. When I first wrote about this I got back a note from the WordPress XML-RPC team saying they were planning on doing this. - Dave Winer

I know some people don't like XML-RPC, never really heard a good reason why (emphasize "good"), but it's fairly popular and a deep part of the culture in at least a few corners of network development. So just wanted to add this to the mix, so people can think about it. I may work on this, may not -- we'll see how it goes. XML-RPC is now 11 years old, it might be time to think about what comes next. :-) - Dave Winer

In my Java framework on top of Spring, I use JAXB to serialize/deserialize objects. Extremely simple, convenient, and concise. I find XML-RPC a little bit verbose and not necessary in my case (since I have JAXB on the server). If I wanted to expose services to other application, I would just publish the XML. The param/array/value XML notations is just a unnecessary level of indirection (IMO). I might be missing your point though. - Jeremy Chone

If I had to do it over again I would have argued against that extra level in there, but it's all handled in the low-level code, written once then forgotten, so it hardly matters. If I do a new serialization format that's one of the things I'll change, probably. - Dave Winer

Don't look at me. I'm using a 50-year-old serialization format. - Bruce Lewis from fftogo

CORBA? - Dave Winer

S-expressions - Bruce Lewis from fftogo

Add a JSON serialization of XML-RPC (maybe something like http://bitworking.org/news... because JSON is trendy and all), and I agree this covers the 80% case well. - DeWitt Clinton

ASN-1? - Todd Hoff

To me, XML just seems wrong for serialization. It sits in the perfect nexus of simultaneously being less human readable than JSON, S-Expressions, or YML, and less efficient than ASN.1 DER, ProtocolBuffers, CORBA, etc. It hit a sweet spot of dev activity in the late 90s/early 00s when the future looked like XML for everything, but now JSON looks like the sweet spot. In my own case, My apps need to deserialize on mobiles, consume the least battery power with lowest network latency, so I prefer efficiency - Ray Cromwell

Not likely that I'm going to do work in JSON, since I have highly optimized XML parser built into my dev environment. Debugged, no memory leaks, crashes, etc. Don't want to go through all that again. However, there's nothing to say that a parallel project couldn't do the exact equiv in JSON, if it makes some people happy. :-) - Dave Winer

BTW, I didn't want to do XML. It was exactly like this mood people are in about JSON, just do this and everything will be cool forever they promised. I said Yeah sure, until a new group of yunguns comes along and wants to rip it all up -- again. And again. It'll happen again, no doubt. - Dave Winer

"All this has happened before, and it will happen again." - Ray Cromwell

So say we all Ray :-) - Todd Hoff

"REST could take advantage of this work" - REST has more or less designed out remote procedures calls in favour of state transfer. How can REST take advantage? - Bill de hÓra

"My apps need to deserialize on mobiles". Ray, interesting then there aren't any (I think) json or asn.1 libs for mobile, it's all XML. I was surprised that Android didn't ship with a protobufs library. - Bill de hÓra

Android does ship with the org.json library included. I currently use ProtoBufs for Android, but the format is still less than ideal for my uses compared with ASN.1 due to its inefficiency in coding arrays of primitives, as well as ASN.1's better representation of variable length numbers. - Ray Cromwell

Serialization and deserilization is a complete waste anyway. Keep the data encoded in a serialized buffer. Decode it on reads and encode on writes. This is vastly more efficient. - Todd Hoff

This is exactly what I do right now. When data is updated, I encode to ProtocolBuffer and JSON and write both to disk in a way that can be served by nginx or a CDN. REST requests then become simple redirects if the data is valid. For mobile, the coding efficiency and we are decoding performance as importance, because they affect battery life (burn CPU and radio), as well as increase subjective latency in the UI. - Ray Cromwell

ProtocolBuffer doesn't keep a serialized format though. It's serialized and deserializes. I traced the code at one time so I'm sure that's what it does. The BER is space efficient, not CPU efficient, so I'm not sure that would work out. Keeping a serialized buffer means only skipping through memory and incurring costs for what you use. That's very efficient. - Todd Hoff

"How can REST take advantage?" REST apps still have to pass data back and forth, and most of what XML-RPC is is a format for serialization of the kinds of data apps pass back and forth. Rather than create a new format every time and write code every time. I don't particularly mind this work, it's like doing a crossword puzzle but not as interesting. If I could pass off the serialization to a library I'd be done that much sooner. And I wouldn't have to read docs (not that there ever are very many). - Dave Winer

Dave, agree with all of that - what you're talking about re formats I call "precious snowflake syndrome" . Would you agree that we know enough about REST now that the XMLRPC methods can be lifted into HTTP with the it-just-doesn't-fit ones going to POST? One thing I didn't enjoy about XMLRPC was doing fetches, updates and deletes over POST (fetches don't cache, deletes have a security impact). Where I think a son of XMLRPC is valuable is for partial updates (eg updating just the status of a profile field) - Bill de hÓra

You can use whatever you want from XML-RPC for whatever you want, just be careful what you call it so it's not confused with the package of functionality that is XML-RPC. A few years ago, Jeremy Allaire and I proposed something we called RSS-Data that broke apart XML-RPC from the transport. Didn't go very far back then. Maybe worth another look. http://radio.weblogs.com/0113297... - Dave Winer

@Todd, I'm not sure what you mean by PB's not keeping a serialized format. You take a PB, you write it to disk, the disk format is a a serialized representation of the object. BER and DER might not be CPU efficient, but parsing ASCII to Integer a few thousand times to deal with XML or JSON formatted numbers is a whole heck of a low more inefficient. - Ray Cromwell

Ray, I mean that serialization and deserialization are needed to access attributes. It's that process that's inefficient and every hop that touches the data pays the penalty. - Todd Hoff

True, unfortunately, most of the languages out there lack the ability to just mmap() a file and cast it to a (Foo*). Java has "DirectBuffer"s, but reading doubles, longs, ints, still involves bit shifting operations. - Ray Cromwell

I disliked the default XMLRPC model as it was dependent on param ordering and thus more fragile than the HTML forms name+value passing, making default values and adding new named parameters hard. JSON is a better match to dynamic languages natural structures (being valid JS and Python), and much terser. - Kevin Marks

There's also JSON-RPC, though I don't know if anyone uses it. http://en.wikipedia.org/wiki... The advantage of JSON is that it's relatively compact, easy to parse, very popular (many libraries), and maps directly to native data-structures (because that's all it is). It's not great for binary data though. XML-RPC structs are very similar to JSON, except that the layers of wrapping make them harder to read in my opinion (and of course larger). - Paul Buchheit

@Paul, I believe if you look at Apache Shindig, or some OpenSocial container implementations, they are using JSON-RPC underneath to make OpenSocial API requests. I know the PHP Apache Shindig/Partuza does this. - Ray Cromwell

"There's also JSON-RPC" Given my reference points with Atom/REST, I think I'd like a JSON Publishing Protocol - JsonPub ;) The thing with json-rpc is that you seem to be able to get 80% of it with forms posting (altho' sending lists are messy). Then again the way couchdb slings data is cool http://tinyurl.com/2dfy69 - Bill de hÓra