I have a gallon of some wonderful orange kool-aid over here, if you want some. C'mon, you know you do...

XML-RPC can do that, but people don't usually let it.

That's why RESTful APIs are so great. Simple, standard and clean.

I think it comes from a desire to make it map onto the function constructs of programming languages. Most programming languages accept positional parameters. Of course, you can just have one positional parameter that is an associative array, but that doesn't feel “native” enough. XML-RPC has “structs” which are essentially associative arrays, but no-one seems to want to use them.

My stalled RPC-like thing for OpenID doesn't even use named parameters. The “parameters” are just a bunch of XML elements. Of course, the contents of these should be designed with limited XML parsers in mind: I intentionally made the profile exchange call simple enough that you can just use an event-based parser if you want, since it'll make it much easier to implement far and wide. I should finish that some day, but I just got angry with the state of the XML-related modules in CPAN and stopped working on it.

... except that "real" programming languages are often strongly-typed, so at least you know if you passed the wrong thing, will tell you from the word Go if there aren't enough arguments, and have mechanisms for dealing with a variable number of arguments (printf(3)).

But, really, positional parameters haven't been the "native" way to do this since C. We outgrew this ages ago, but the people writing code to do HTML mark-up typically never got past their intro-to-CS class (which, even when they're taught in Java these days and OOP is vaguely mentioned, don't really instill any real software development skills), and have certainly never heard of SICP.

the extendedPing used positional parameters because it was simply a straightforward extension of the already-defined ping interface.

i agree that named parameters are the way to go, but in order to ease adoption, i thought it was more prudent to do the simplest possible extension and stick with general xml-rpc practice.

and the extendedPing interface was defined over four years ago, it's not exactly a recent extension.

and the extendedPing interface was defined over four years ago, it's not exactly a recent extension.

Nothing better's come along?

So far the pinging community isn't impressing me. Both blo.gs and technorati won't even support connection keep-alive on their rpc servers, so LJ can't even ping them at a fast enough rate, and I'm wondering if it's even worth it, considering the only pings I see in a lot of these services updated lists are spam.

the best thing for livejournal to do would be to publish a stream of updates as in the blo.gs cloud/feedmesh interface. it's also a sort-of-wonky format, but it makes a lot more sense than doing a ping on every update.

pubsub.com also supports the cloud/feedmesh interface - you can connect to port 9999 on sandbox.pubsub.com to see what it looks like.

the spam problem is not being fought very well. looking at the new blogs at blo.gs, the current prolific spammers appear to be coming in via weblogs.com, as usual.