[twitter-dev] Re: A Fresh Approach To Follower Processing

2009-06-11 Thread jstrellner
This would be VERY useful to us. Although for our needs, a stream might be overkill. But if each request for the social graph data can come with a request ID, or even an exact time stamp, which we could provide on the next request and get a diff between the two calls, it would help a lot. If

[twitter-dev] Re: A Fresh Approach To Follower Processing

2009-06-11 Thread Dewald Pretorius
I wouldn't want to sit at the receiving end of a full follower transaction stream. I will be getting millions of transactions that I have no interest in. That's why I suggested Gnip. Let them sit in front of the firehose, and funnel what I need into user-specific garden hoses. Dewald

[twitter-dev] Re: A Fresh Approach To Follower Processing

2009-06-11 Thread Doug Williams
It would be a subset similar to /follow or /birddog, not the entire social graph. But again, what is your use-case? Thanks, Doug On Thu, Jun 11, 2009 at 9:31 AM, Dewald Pretorius dpr...@gmail.com wrote: I wouldn't want to sit at the receiving end of a full follower transaction stream. I

[twitter-dev] Re: A Fresh Approach To Follower Processing

2009-06-10 Thread Jesse Stay
I've proposed this with Alex before, but yes, this would be very useful to me. Jesse On Wed, Jun 10, 2009 at 4:00 PM, Dewald Pretorius dpr...@gmail.com wrote: Currently all of us are using the delta between a certain follower social graph snapshot and a subsequent follower social graph

[twitter-dev] Re: A Fresh Approach To Follower Processing

2009-06-10 Thread Doug Williams
There has been discussion of pushing social graph changes through the streaming API in much the same way that Dewald has requested. At this time there is nothing to report nor a definitive decision on if it will ever be publicly available. I know Jesse's use case from an earlier thread but are