Scripting News for 11/12/07

More breakage in the Flickr API? 

A few days ago I reported here that some code that built on the Flickr API that had worked properly for months had broken. It turned out that the people at Yahoo had fixed a bug in the way the API worked. They were permitting anyone to download all sizes of a picture, when (they believed) this should only be available to the creator of the picture. My code didn’t try to sign the user in (there was no need to), so all of a sudden I was getting mysterious errors from my code saying that it couldn’t locate an object called “Original.” It took some time to trace it down, and by searching on the net for other people who were having the same problem, and figure out how it related to my code.

When I got to the bottom of the fix, figured out what they changed, and remembered how my code worked, it was easy to fix. But these were hours that I should have spent fixing other bugs, or creating new features for my users.

I put it behind me until it happened again, today. Some code that had worked for a long time is now broken. I spent most of today trying to understand, again, what a token is and a frob and how they relate. I have to admit, that when I first implemented this code I didn’t really understand what they these things are, but I fumbled around until the code worked and moved on. But now I’m back to where I was, and wondering whether there’s any point in trying to fix this problem. How long before something else breaks?

Right now I have a very small number of users, and most of them are not affected by these breaks. But what happens when there are more users, or something changes that breaks more of them. They’re not going to be so understanding, I’m not going to be able to pass the buck. I’m going to be wrong, if that should happen, for choosing to build on Flickr. Is this really a position that Flickr wants to put us in??

I’m familiar with the thinking that one should fix problems in the code behind an API, that when you discover a bug it’s just like a bug in normal software. The first time I made a change in Frontier that broke developers (including myself, btw) I understood why you have to live with the bugs once people have built on your API. To this day there are bugs in Frontier, lovingly preserved. If they were fixed, it would cause an unknown and therefore unacceptable amount of breakage.

I build on top of a lot of web apps, not just Flickr, and so far all has been good, until this round of breakage. It’s a warning to everyone to live with your bugs. If you really must fix them, come up with new entry-points that work the way you think they should, or employ optional parameters. No matter what, breakage is not acceptable, not like this.

And also, if you’re going to be in the business of breaking developers, get very very good at communicating, and explaining carefully what the change is, that way when we’re down, we have a chance of picking up the pieces quickly. I don’t have any idea where to go to see a log of changes made behind the Flickr API. Not saying there isn’t such a place, it just needs to be more obvious where it is.

Here’s what I know about today’s problem. When I call flickr.auth.getToken with a frob returned by flickr.auth.getFrob, I get error code 108: Invalid frob. “The specified frob does not exist or has already been used.”

I don’t know where to go from here. I’m just sending back to Flickr something they sent me. As I said above, this has been working for months. Of course I’ve tried searching for others who have had the problem, but I still don’t know where to go. Any help would be appreciated, of course.


Just watched the video demo of Android, it looks good.

I downloaded the SDK and have no idea what to do with it. I’m not a Java programmer.

I think the guy nailed it up front. I’m not going to be able to really figure out what if anything I can do with this product until I have one in my hands, and that’s going to take a while for them to get to.

Showing me the guts of the development platform first is putting the cart before the horse. I lack the motivation. And any product I work on is going to be coded, at this level, by someone else.

I appreciate the emails I’ve been getting from Google people, I want to like your product, and the demo really does look good.

PS: I’ve long felt that platform vendors should pay developers, now that I’ve heard the pitch first-hand, I think I’d like it to be more subtle. How about giving real money to developers based on the number of users they draw to the platform? That might feel a little better.

To Paul Boutin re Davos 

Just read your snarky bit about Mike’s invite to Davos, but it’s still a great deal even if you’re not speaking. Much of Davos is done unconference style, the lunches and dinners are basically roundtables with about 30 to 50 people at the table and the conversation is structured by a discussion leader, usually someone who’s expert in an area, an economist or an astronaut, or an indigenous person who lives in a rainforest being destroyed by drug companies (and the drug company’s CEO is probably there too). The conversations are generally very interesting, and often heated. Going to Davos with a white badge is not only an honor, but it’s a great deal of fun, and educational. There’s no doubt Mike will have a great time, and his reports will likely be interesting reads. It’s definitely worth being envious of! 🙂

One response to this post.

  1. Date: Tuesday, November 13, 2007 08:00 am CST

    Subject: API problems…

    Sorry to hear about your API problems, Dave — obviously you have experienced the identical situation many times before — so, why don’t you do something to fix the problem, once and for all??

    You DO have the power, you know?? You have a following — which makes you a “gatekeeper” — which means that you could use that power to mount a campaign to develop solutions.

    I assume that you would agree that the magnitude of the problem you describe is inversely proportional to the amount of testing encountered by the respective APIs — and that it is pretty hard to hold some small scale developer to task after allowing the almighty leader off the hook without establishing a proper business model.

    Dave, it doesn’t do any good to admonish the people that broke your code — after all, the system doesn’t pay them to thoroughly test their code — they must gamble, and keep their fingers crossed.

    We need to back up and build a proper software development environment that allows average developers to make a decent living — while doing adequate testing.

    Need I say more??

    Doug Skoglund

    Product Information –

    Off-line discussion forums –


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: