No. If we are to offer real-time social graph changes, they'll be via the Streaming API. In the mean time, there is no low-latency high- throughput way to determine changes to the social graph. Attempts to simulate this at large scale via repeated polling are likely to be frustrating.
-John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Oct 6, 11:12 am, "Brian Smith" <br...@briansmith.org> wrote: > John, > > Based on your description, it looks like you are on the verge of being able > to offer a very useful capability: the ability to query the follows AND > unfollows since the last time you checked. That would be a great addition to > the API. > > For example, I'd really like to be able to page through A, B, C, etc. And > then, after that, say "OK, what's changed since then"? > > Regards, > Brian > > > -----Original Message----- > > From: twitter-development-talk@googlegroups.com [mailto:twitter- > > development-t...@googlegroups.com] On Behalf Of John Kalucki > > Sent: Sunday, October 04, 2009 11:17 PM > > To: Twitter Development Talk > > Subject: [twitter-dev] Re: Twitter, Please Explain How Cursors Work > > > I haven't looked at all the parts of the system, so there's some > > chance that I'm missing something. > > > The method returns the followers in the reverse chronological order of > > edge creation. Cursor A will have the most recent 5,000 edges, by > > creation time, B the next most recent 5,000, etc. The last cursor will > > have the oldest edges. > > > Each cursor points to some arbitrary edge. If you go back and retrieve > > cursor B, you should receive N edges created just before the edge- > > pointed-to-by-B was created. I don't recall if N is always 5000, > > generally 5000 or if it's at most 5000. This detail shouldn't matter, > > other than, on occasion, you'll make an extra API call. > > > In any case, retrieving cursor B will never return edges created after > > the edge-pointed-to-by-B was created. All edges returned by cursor B > > will be no-newer-than, and generally older than, than the edge-pointed- > > to-by-B. > > > So, all future sets returned by cursor B are always disjoint from the > > set originally returned by cursor A. In your example, if you refetched > > both A and B, the result sets wouldn't be disjoint as there are no > > longer 5,000 edges between cursor A and cursor B. > > > I think this, in part answers your question. ? > > > -John Kalucki > >http://twitter.com/jkalucki > > Services, Twitter Inc. > > > On Oct 4, 6:10 pm, Dewald Pretorius <dpr...@gmail.com> wrote: > > > For discussion purposes, let's assume I am cursoring through a very > > > volatile followers list of @veryvolatile. We have the following > > > cursors: > > > > A = 5,000 > > > B = 5,000 > > > C = 5,000 > > > > I retrieve Cursor A and process it. Next I retrieve Cursor B and > > > process it. Then I retrieve Cursor C and process it. > > > > While I am processing Cursor C, 200 of the people who were in Cursor > > A > > > unfollow @veryvolatile, and 400 of the people who were in Cursor B > > > unfollow @veryvolatile. > > > > What do I get when I go back from C to B? Do I now get 4,600 ids in > > > the list? > > > > Or, do I get 5,000 in B, which now includes a subset of 400 ids that > > > were previously in Cursor A? > > > > Dewald
