First off, thanks for the heads up and giving us a large lead time. It's what I asked for in a previous email, and even if you never read that email and this isn't a response to me at all. I'll say thanks anyway, because it's great. :-)

But, forgive me if I'm off base, but you're saying this change is going to happen just like a switch. One minute the API will behave one way, then next minute the API will behave differently?

Doesn't this level of behavior change merit a bit of a deprecation period where both behaviors function?

After a sudden change any app still using the old behavior is guaranteed to fail. If the app fixes early then it will fail up until the api change. In other words, ALL APPS that use this api call WILL be guaranteed to FAIL for some period of time. That seems like a pretty ugly prospect.

Many api temper this sort of change in behavior by adding a new method call or a new argument to the method call. And for some period of time letting both function while marking the old method deprecated, use at the risk of being abandoned without warning at the next update. This lets apps update from one functioning call to another functioning call without users experiencing any downtime.

I understand that some changes might need to be rolled in quickly to avert infrastructure disaster or to patch security holes, but with 2 weeks notice, I'm guessing that's not what we're dealing with here.


YourHead Software

On Jul 31, 2009, at 11:09 AM, Arik Fraimovich wrote:

On Jul 31, 9:03 pm, Alex Payne <> wrote:
To clarify, since several people have asked: this pending change does
NOT mean that pagination is required. You can still attempt to
retrieve all IDs in one call, but be aware that this is likely to time
out or fail for users with large social graphs.

What is defined as "large social graphs"?

Arik Fraimovich
follow me on twitter:

Reply via email to