The Blogger folks posted a Blogger API Update. The gist of it: they will continue to support the Blogger 1.0 API, and they will also support Echo in the future.
Okay, that makes sense. It’s not my personal preference, but it makes sense.
One thing kinda pissed me off: “We are moving away from XML-RPC,” they write.
The thing is, I’ve already been so pissed at Blogger lately. They’ve been moving servers and sites around, and their support for the Blogger API keeps breaking, so I have a bunch of people sending me bug reports about null Java exceptions and stuff—errors on the Blogger side when people try to post to their weblogs.
It’s been so bad that I even thought about dropping support for Blogger in NetNewsWire’s weblog editor. But I won’t do that because there are people who bought NetNewsWire to edit their Blogger weblogs, and these people are far more important than my being pissed off at Blogger.
The Blogger folks continue: “If you choose to take advantage of the capabilities of the new API, you will need to use SOAP instead of XML-RPC. This was a difficult decision (made collectively by the designers of Echo), because there is a lot of investment in XML-RPC in the blogging tool space, and it is great for getting things done quickly.”
Okay, if this is true, I totally missed it. My fault. Will the Echo API mandate SOAP rather than XML-RPC?
It seems like my to-do list is getting longer every day with crap. I want to do bug fixes and cool new features (Web Kit, synching, Rendezvous support, etc.). I don’t want to have to deal with SOAP. Feh.
A new syndication format, okay, a new editing API, okay, but now I have to use SOAP?
From the user’s point of view, they just want to be able to use titles with their Blogger posts. Seems like it should be simple.
I’ll use SOAP if I have to. Of course I will.
I keep seeing phrases like “benefits to users and developers...” Which makes me laugh.
The Ministry of Benefits to Developers and Users—where “benefits to developers” means you have to do a bunch of extra work on things that you already had nailed down. Where “benefits to users” means users have to wait for the features they’re excited about because the developers are too busy dealing with all the wonderful “benefits” they’re having to support.