Dan MacTough › Likes

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

Johnny, did you install that file I posted instead of the original MRSS file? http://www.blastoffgames.net/codesha... You have to rename it to mrss.php and drop it in your wp-content/plugins directory. Activate it and make a post with an image in it and publish it. Then look at your RSS feed source and see if there's a media:thumbnail for that item. - Paul Reynolds

Awesome, thanks, will let you know how it goes - Johnny Worthington

Dang. Now I totally need some gingerbread cookies. I may have to go to the grocery store, at 8:15 Sunday night, to satisfy a gingerbread craving. - Ladybug Heather

You guys will be doing online stuff too, right? I guess I could just click the damn link, but please pardon my laziness... - Bran Mydwynter

Paul: Just got a bunch of errors on my rss feed: "error on line 35 at column 23: Namespace prefix media on thumbnail is not defined" http://www.johnworthington.me/... - Johnny Worthington

Yep. So you need to edit that mrss.php file. Open it in a text editor (or you can actually edit it inside WordPress). In that file, you need to cut the xmlns:media="http://search.yahoo.com/mrss" text (leave the /* and */ alone or delete them) and paste it between the ?> and <?php Then republish! You should be good to go. I had another plug-in that was putting that xmlns tag in my feed already and so I had to take it out. - Paul Reynolds

@Bran: We're going to be very online oriented. The biggest feature being that customers can upload photos of their dogs and we'll print them on the packaging for them. If they grant us license to use the photo, and we choose to use the photo, it will get put on the bags sold in the retail store and we'll send some free treats their way! I'm coding it all up now, so it remains to be seen exactly when the online portion will be working. Within 2 weeks. - Paul Reynolds

Champion... - Johnny Worthington

James, the way I read that Wikipedia entry, it seems that scalability currently is only a concern in multi-user chat. IANAE, but I don't think that's relevant to Twitter's use of XMPP -- they run a bot. Thoughts? - Dan MacTough

Dan, They might only run a bot however all the traffic goes to Twitter's servers. I don't have the numbers but that could require a lot of data bandwidth which should really not be their concern. Basically they need to offload that service to something like Amazon's Elastic cloud. - James Robertson

So it's a Twitter architecture issue, not an XMPP scalability limitation. Right? - Dan MacTough