http://code.google.com/p/twitter-api/issues/detail?id=142
On Sat, Apr 18, 2009 at 12:32, lordofthelake <h1dd3n...@yahoo.it> wrote: > > Hello. > I started a project whose goal is to allow users to track the reaction > of the crowd to their posts. This includes showing all the replies and > retweets born as reaction to the original message, organizing the data > in a threaded schema. While finding retweets of a particular message > is fairly easy using the Search API (Query: "RT @user <some words of > the message>"), finding and filtering all the replies can become a non- > trivial work quite fast. > > While tracking the replies given directly to you isn't particularly > hard, though not very efficient (find posts directed to you via search > API -- "to:user since_id:<tweet id>" -- and then filter by > in_reply_to_status_id), it becomes a nightmare when you want to track > what your followers' friends have answered to the replies you got from > your own followers. > > Example of conversation: > Me: any idea about how to track the whole conversation originated from > this tweet? > MyFollower: @Me try posting in the twitter dev talk, maybe they can > help you > AFollowerOf_MyFollower: @MyFollower I know for sure those guys are > very supportive > > Tracking MyFollower's response is not a big deal, even if the "first > fetch them all, then select those you need" may not be the most > efficient to implement for large volumes of tweets -- think to the > power-users with thousands, if not millions, of followers -- since > above certain limits, API usage caps (especially about number of > tweets that can be retrieved at once) start becoming an issue. > > The real problem comes when you want to show in the threaded > conversation AFollowerOf_MyFollower's tweet, too. Sure thing, you can > use the same strategy as above (Search "to:MyFollower", fetch all, > filter by in_reply_to_status_id), but now instead of having to do a > single query (to:Me) to retrieve the replies to your posts, you have > to perform a fetching and filtering cycle for every person who took > part to the conversation: the growth is exponential. > > A solution may be to allow searches by in_reply_to_status_id > (something like "reply:<status id>")... this would greatly lower the > cost of looking for replies to your posts. Would it be possible to > have such a feature exposed in future? Are there other, more efficient > solutions, anybody can suggest to solve my problem efficiently? > > Thank you for the support. I apologize for the long post and my bad > English, but I'm not a native English speaker and I tried to expose my > problem as clearly as I could. > -- Michele > -- Abraham Williams | http://the.hackerconundrum.com Hacker | http://abrah.am | http://twitter.com/abraham Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private. Sent from Madison, Wisconsin, United States
