Log in

named parameters.... CS rocket science, apparently - brad's life [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

named parameters.... CS rocket science, apparently [Aug. 1st, 2005|03:05 pm]
Brad Fitzpatrick
[Tags|, ]

Has nothing been learned by the blogging community about web services?

As if the Blogger and metaweblog API weren't bad enough with positional parameters (which were then overloaded with magical means, like <subject> in the body positional parameter meant a subject was included, which was then parsed out), we now have blo.gs or whoever extending the "ping" API with "extendedPing" which just adds more positional parameters.

What's so hard about named parameters? That's a "hash" or "dict" or "collection" or "associative array" depending on your language. *sigh*

[User Picture]From: midendian
2005-08-01 10:15 pm (UTC)
In the XML-RPC case, blame Dave Winer. (I could be SOAP-free if XML-RPC didn't have that one ridiculous flaw.)
(Reply) (Thread)
(Deleted comment)
(Deleted comment)
[User Picture]From: xb95
2005-08-01 10:18 pm (UTC)
I have a gallon of some wonderful orange kool-aid over here, if you want some. C'mon, you know you do...
(Reply) (Thread)
[User Picture]From: j7xz49br3m93xrr
2005-08-01 11:07 pm (UTC)
XML-RPC can do that, but people don't usually let it.

That's why RESTful APIs are so great. Simple, standard and clean.
(Reply) (Thread)
[User Picture]From: mart
2005-08-02 07:22 am (UTC)

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.

(Reply) (Thread)
[User Picture]From: grumpy_sysadmin
2005-08-03 02:37 pm (UTC)
... 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.
(Reply) (Parent) (Thread)
From: jimw
2005-08-02 04:36 pm (UTC)


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.
(Reply) (Thread)
[User Picture]From: brad
2005-08-02 05:15 pm (UTC)

Re: extendedPing

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.
(Reply) (Parent) (Thread)
From: jimw
2005-08-02 05:27 pm (UTC)

Re: extendedPing

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.
(Reply) (Parent) (Thread)