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.
Isaiah
YourHead Software
supp...@yourhead.com
http://www.yourhead.com
On Jul 31, 2009, at 11:09 AM, Arik Fraimovich wrote:
On Jul 31, 9:03 pm, Alex Payne <a...@twitter.com> 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: http://twitter.com/arikfr
