Thanks for the link.
On Apr 18, 7:40 pm, Abraham Williams <[email protected]> wrote: > http://code.google.com/p/twitter-api/issues/detail?id=142 > > > > On Sat, Apr 18, 2009 at 12:32, lordofthelake <[email protected]> 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
