[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
John, thanx for your comment over at groovyconsole.appspot.com - http://groovyconsole.appspot.com/view.groovy?id=19003 In case you do not get updates on comments there, let me ask my main question again. This would make my (our) lives a lot easier when it comes to retweet tracking, still it would not require me to use the streaming API: If we could pass multiple status ids into the statuses/retweets method in which case it returns summaries for each tweets retweets like the count, only the screennames that retweeted, etc. I could keep it on one system. It would help me a lot. Are you investigating support for this? Is this under consideration? Thx Sven On Sep 24, 9:50 am, John Kalucki jkalu...@gmail.com wrote: I'll update the Wiki to reflect the new reality. Retweetswill begin to flow through all /1/statuses/* resources soon -- in advance of the full retweet launch. This will give developers time to test and deploy features in advance. Also, the retweet volume is very low now, so exceptions should be easier to handle. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Sep 23, 10:15 pm, hansamann sven.hai...@googlemail.com wrote: John, I assume the method to use would then be http://stream.twitter.com/1/statuses/filter.format It does not mention that it includesretweets, but it will once the API is live? Cheers Sven On Sep 23, 9:38 pm, hansamann sven.hai...@googlemail.com wrote: Thanx, I'll give that a try. On Sep 23, 8:11 pm, John Kalucki jkalu...@gmail.com wrote: Retweetswill be searched by the follow parameter on the filter resource. The intention is that you get all statuses (including retweets) where any user_id field matches your predicate list. So, tweets, replies and both ends ofretweets. If GAE cuts you off after 30 seconds, then you shouldn't open connections to the Streaming API. Gather ye data elsewhere and smuggle it into GAE by other means. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Sep 23, 7:50 pm, hansamann sven.hai...@googlemail.com wrote: One reason for example is being on Google App Engine and having a 30 second limit. I cannot keep the connection open. Another reason is I am not interested in everyonesretweets, just the retweets(and in this case all, not just a sample) of that twitter user's friends. What do you think? Cheers Sven On Sep 22, 9:49 pm, John Kalucki jkalu...@gmail.com wrote: Retweetaggregators should use the Streaming API /1/statuses/sample method to gather a sample ofRetweetsor apply for the fullRetweet stream on /1/statuses/retweet. The Streaming API may be in Alpha, but the service has been very reliable. I'm unaware of any technical issues that would block a reasonably proficient service developer on a reasonable stack from integrating Streaming API results in fairly short order. I'm sure there are examples of byzantine stacks upon which this isn't true, but workarounds can be found. -John Kaluckihttp://twitter.com/jkalucki Services, TwitterInc. On Sep 22, 9:27 pm, hansamann sven.hai...@googlemail.com wrote: I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to trackretweets. What we are really interested in is the number ofretweetsover time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning severalretweetcounts? So what if statuses/retweetswould either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweetcounts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweetsfor single tweets cannot be the intention of Twitter. Also manyretweetaggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for trackingretweetsafter the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
I'll update the Wiki to reflect the new reality. Retweets will begin to flow through all /1/statuses/* resources soon -- in advance of the full retweet launch. This will give developers time to test and deploy features in advance. Also, the retweet volume is very low now, so exceptions should be easier to handle. -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Sep 23, 10:15 pm, hansamann sven.hai...@googlemail.com wrote: John, I assume the method to use would then be http://stream.twitter.com/1/statuses/filter.format It does not mention that it includes retweets, but it will once the API is live? Cheers Sven On Sep 23, 9:38 pm, hansamann sven.hai...@googlemail.com wrote: Thanx, I'll give that a try. On Sep 23, 8:11 pm, John Kalucki jkalu...@gmail.com wrote: Retweets will be searched by the follow parameter on the filter resource. The intention is that you get all statuses (including retweets) where any user_id field matches your predicate list. So, tweets, replies and both ends of retweets. If GAE cuts you off after 30 seconds, then you shouldn't open connections to the Streaming API. Gather ye data elsewhere and smuggle it into GAE by other means. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Sep 23, 7:50 pm, hansamann sven.hai...@googlemail.com wrote: One reason for example is being on Google App Engine and having a 30 second limit. I cannot keep the connection open. Another reason is I am not interested in everyones retweets, just the retweets (and in this case all, not just a sample) of that twitter user's friends. What do you think? Cheers Sven On Sep 22, 9:49 pm, John Kalucki jkalu...@gmail.com wrote: Retweetaggregators should use the Streaming API /1/statuses/sample method to gather a sample of Retweets or apply for the fullRetweet stream on /1/statuses/retweet. The Streaming API may be in Alpha, but the service has been very reliable. I'm unaware of any technical issues that would block a reasonably proficient service developer on a reasonable stack from integrating Streaming API results in fairly short order. I'm sure there are examples of byzantine stacks upon which this isn't true, but workarounds can be found. -John Kaluckihttp://twitter.com/jkalucki Services, TwitterInc. On Sep 22, 9:27 pm, hansamann sven.hai...@googlemail.com wrote: I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to track retweets. What we are really interested in is the number of retweets over time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning severalretweetcounts? So what if statuses/retweets would either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweetcounts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweets for single tweets cannot be the intention of Twitter. Also manyretweetaggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for tracking retweets after the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for eachretweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
I'm seeing retweet_details information appearing in the payload of the statuses/show call. Is this normal behavior? Try this curl http://twitter.com/statuses/show/4297637412.xml Thanks - Martin On Sep 18, 4:57 pm, Marcel Molina mar...@twitter.com wrote: The Retweet API launch is close at hand. You might have already seen some retweets appearing in the new statuses/home_timeline from people who've been testing them out. We've gotten lots of great questions and feedback about the retweet API. Thanks to everyone who has rolled up their sleeves and gotten involved. It's been a big help. One of the main confusions and criticisms about the retweet API was around what happens when a given tweet is retweeted multiple times. The explanation was that developers need to do their own retweet collapsing. If N people retweet a given tweet, you'd get N instances of that same tweet in the appropriate retweet timeline and the home timeline. You would then have to do your own internal book keeping about whether that tweet had already come in. If it hadn't you'd display it for the first time. If it had you'd update the already displayed tweet. Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the first retweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Here is the documentation for the new resource, statuses/retweets:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets Sincere apologies if you've already written collapsing logic for retweets. Beta releases are beta releases and I think the retweet API is a lot better without the onerous collapsing requirement. To give you some ideas of how you can use the API to display retweets, here is a recent mock up of one of the potential UIs for the retweets timeline on twitter.com:http://a1.twimg.com/example-retweet-ui-18-sep-09.png If you've got questions, find bugs, or have any kind of feedback, get in touch via the dev mailing list, send an @reply to @twitterapi or jump into the #twitterapi IRC channel on irc.freenode.net. -- Marcel Molina Twitter Platform Teamhttp://twitter.com/noradio
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
Maybe this isn't the right place, but... From a developer perspective I love the retweet API and it's potential uses. As a regular twitter user, I'm less thrilled. Once this is in place, is it going to fundamentally what/how I see my public timeline? If the mockups are anything to go by, it looks less useful. If someone I'm following retweets something from SarahKSilverman, I don't want to see SarahKSilverman appear in my timeline. I want to see the person I know, that way I can easily attribute it with the appropriate amount of importance and credibility. This issue becomes even more pronounced when lesser known individuals are the source of the original tweet, and when the topic being retweeted becomes more niche. Or have I completely misunderstood the final implementation/ implications? Thanks, Glenn
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
As a regular twitter user, I'm less thrilled. Once this is in place, is it going to fundamentally what/how I see my public timeline? If the mockups are anything to go by, it looks less useful. If someone I'm following retweets something from SarahKSilverman, I don't want to see SarahKSilverman appear in my timeline. I want to see the person I know, that way I can easily attribute it with the appropriate amount of importance and credibility. This issue becomes even more pronounced when lesser known individuals are the source of the original tweet, and when the topic being retweeted becomes more niche. The nice thing about being an API client is that you can, of course, change how the tweet is presented. In fact, that is exactly my plan for TTYtter to change retweets so that they come from the person who RTed it, not the person being RTed (who appears appended). Still, I'm sort of with Dewald and others that I'm really having a hard time seeing what the RT API buys, and I can see quite a few things that the old manual way does better. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Smile! God loves you! --
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
I think the new RT API is an attempt to turn related tweets into a computer-parseable conversation. Humans can fairly easily determine what it part of an existing conversation by reading the different tweets and using contextual clues, but computers cannot. The small benefit to us humans is that clients may be more able to present tweets as a threaded conversation if they understand that discreet tweets are, in fact, part of a conversation. The large benefit to Twitter and corporations is that they can more easily track social behavioral patterns (== more finely targeted marketing and advertising and ROI calculations). Fortunately, it's all opt-in. Unfortunately, it's all opt-in. I'm with the others, though, that IMHO retweets should not be deleted if an original retweet (or one up in the chain? dunno) is deleted. Possibly it's only in there because this (having gaps in tweets brought about by deleted tweets) breaks the programmatic ability to follow a thread. Not sure. Joseph Cheek jos...@cheek.com, www.cheek.com twitter: http://twitter.com/cheekdotcom Cameron Kaiser wrote: Still, I'm sort of with Dewald and others that I'm really having a hard time seeing what the RT API buys, and I can see quite a few things that the old manual way does better.
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
One reason for example is being on Google App Engine and having a 30 second limit. I cannot keep the connection open. Another reason is I am not interested in everyones retweets, just the retweets (and in this case all, not just a sample) of that twitter user's friends. What do you think? Cheers Sven On Sep 22, 9:49 pm, John Kalucki jkalu...@gmail.com wrote: Retweetaggregators should use the Streaming API /1/statuses/sample method to gather a sample of Retweets or apply for the fullRetweet stream on /1/statuses/retweet. The Streaming API may be in Alpha, but the service has been very reliable. I'm unaware of any technical issues that would block a reasonably proficient service developer on a reasonable stack from integrating Streaming API results in fairly short order. I'm sure there are examples of byzantine stacks upon which this isn't true, but workarounds can be found. -John Kaluckihttp://twitter.com/jkalucki Services, TwitterInc. On Sep 22, 9:27 pm, hansamann sven.hai...@googlemail.com wrote: I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to track retweets. What we are really interested in is the number of retweets over time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning severalretweetcounts? So what if statuses/retweets would either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweetcounts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweets for single tweets cannot be the intention of Twitter. Also manyretweetaggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for tracking retweets after the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for eachretweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the firstretweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
Is there a way to connect to the streaming api and only get my friends retweets? Or would I get *everyones* retweets and have to filter millions of unwanted messages out? On Sep 22, 9:49 pm, John Kalucki jkalu...@gmail.com wrote: Retweetaggregators should use the Streaming API /1/statuses/sample method to gather a sample of Retweets or apply for the fullRetweet stream on /1/statuses/retweet. The Streaming API may be in Alpha, but the service has been very reliable. I'm unaware of any technical issues that would block a reasonably proficient service developer on a reasonable stack from integrating Streaming API results in fairly short order. I'm sure there are examples of byzantine stacks upon which this isn't true, but workarounds can be found. -John Kaluckihttp://twitter.com/jkalucki Services, TwitterInc. On Sep 22, 9:27 pm, hansamann sven.hai...@googlemail.com wrote: I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to track retweets. What we are really interested in is the number of retweets over time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning severalretweetcounts? So what if statuses/retweets would either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweetcounts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweets for single tweets cannot be the intention of Twitter. Also manyretweetaggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for tracking retweets after the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for eachretweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the firstretweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
Retweets will be searched by the follow parameter on the filter resource. The intention is that you get all statuses (including retweets) where any user_id field matches your predicate list. So, tweets, replies and both ends of retweets. If GAE cuts you off after 30 seconds, then you shouldn't open connections to the Streaming API. Gather ye data elsewhere and smuggle it into GAE by other means. -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Sep 23, 7:50 pm, hansamann sven.hai...@googlemail.com wrote: One reason for example is being on Google App Engine and having a 30 second limit. I cannot keep the connection open. Another reason is I am not interested in everyones retweets, just the retweets (and in this case all, not just a sample) of that twitter user's friends. What do you think? Cheers Sven On Sep 22, 9:49 pm, John Kalucki jkalu...@gmail.com wrote: Retweetaggregators should use the Streaming API /1/statuses/sample method to gather a sample of Retweets or apply for the fullRetweet stream on /1/statuses/retweet. The Streaming API may be in Alpha, but the service has been very reliable. I'm unaware of any technical issues that would block a reasonably proficient service developer on a reasonable stack from integrating Streaming API results in fairly short order. I'm sure there are examples of byzantine stacks upon which this isn't true, but workarounds can be found. -John Kaluckihttp://twitter.com/jkalucki Services, TwitterInc. On Sep 22, 9:27 pm, hansamann sven.hai...@googlemail.com wrote: I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to track retweets. What we are really interested in is the number of retweets over time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning severalretweetcounts? So what if statuses/retweets would either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweetcounts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweets for single tweets cannot be the intention of Twitter. Also manyretweetaggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for tracking retweets after the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for eachretweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the firstretweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
Thanx, I'll give that a try. On Sep 23, 8:11 pm, John Kalucki jkalu...@gmail.com wrote: Retweets will be searched by the follow parameter on the filter resource. The intention is that you get all statuses (including retweets) where any user_id field matches your predicate list. So, tweets, replies and both ends of retweets. If GAE cuts you off after 30 seconds, then you shouldn't open connections to the Streaming API. Gather ye data elsewhere and smuggle it into GAE by other means. -John Kaluckihttp://twitter.com/jkalucki Services, Twitter Inc. On Sep 23, 7:50 pm, hansamann sven.hai...@googlemail.com wrote: One reason for example is being on Google App Engine and having a 30 second limit. I cannot keep the connection open. Another reason is I am not interested in everyones retweets, just the retweets (and in this case all, not just a sample) of that twitter user's friends. What do you think? Cheers Sven On Sep 22, 9:49 pm, John Kalucki jkalu...@gmail.com wrote: Retweetaggregators should use the Streaming API /1/statuses/sample method to gather a sample of Retweets or apply for the fullRetweet stream on /1/statuses/retweet. The Streaming API may be in Alpha, but the service has been very reliable. I'm unaware of any technical issues that would block a reasonably proficient service developer on a reasonable stack from integrating Streaming API results in fairly short order. I'm sure there are examples of byzantine stacks upon which this isn't true, but workarounds can be found. -John Kaluckihttp://twitter.com/jkalucki Services, TwitterInc. On Sep 22, 9:27 pm, hansamann sven.hai...@googlemail.com wrote: I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to track retweets. What we are really interested in is the number of retweets over time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning severalretweetcounts? So what if statuses/retweets would either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweetcounts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweets for single tweets cannot be the intention of Twitter. Also manyretweetaggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for tracking retweets after the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for eachretweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the firstretweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to track retweets. What we are really interested in is the number of retweets over time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning several retweet counts? So what if statuses/retweets would either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweet counts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweets for single tweets cannot be the intention of Twitter. Also many retweet aggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for tracking retweets after the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for eachretweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the firstretweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
Retweet aggregators should use the Streaming API /1/statuses/sample method to gather a sample of Retweets or apply for the full Retweet stream on /1/statuses/retweet. The Streaming API may be in Alpha, but the service has been very reliable. I'm unaware of any technical issues that would block a reasonably proficient service developer on a reasonable stack from integrating Streaming API results in fairly short order. I'm sure there are examples of byzantine stacks upon which this isn't true, but workarounds can be found. -John Kalucki http://twitter.com/jkalucki Services, TwitterInc. On Sep 22, 9:27 pm, hansamann sven.hai...@googlemail.com wrote: I am still hoping for an answer to the questions in this thread, but meanwhile here is another idea the Twitter Team might find interesting. As it seems many of us want to track retweets. What we are really interested in is the number of retweets over time so we can find trending topics, in my case within a community (e.g. not for public timeline tweets, just for the tweets among my friends). So: why not have a method that is capable of returning several retweet counts? So what if statuses/retweets would either accept *just a single id* in which case the behaviour is as currently described, or *many ids* in which case the response is a summary for many statusIds. The summary should contain the usernames that retweeted the original ids and the retweet counts at least. If the API is left as it is, guess a lot of us will need to get whitelisted. Excessively calling status/retweets for single tweets cannot be the intention of Twitter. Also many retweet aggregators will really be in trouble (unless they use the streaming apis, but those again are alpha and some cannot use them for technical reasons) as the twitter accounts of their users are not whitelisted and as such constraint to 150 API calls. Come on, would anyone at least consider that or let us know best practices for tracking retweets after the api is launched? Cheers Sven On Sep 18, 4:37 pm, hansamann sven.hai...@googlemail.com wrote: Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for eachretweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the firstretweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the first retweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
Excactly, my main point, too. The problem is I want to track how tweets 'develop' over time. This means I would need to pull the status/retweets every minute or so for every tweet I am tracking. There is a 150 api call limit currently... without whitelisting I will be doomed. I was hoping that the 'retweeted to me' timeline would include a 'count' field for each retweet. I could then have checked that timeline every minute (and pull the info for the last 50 retweets to me let's say). This would just have consumed 1 request each minute for example... not 1 request per tweet tracked per minute, which... could be a lot. Any ideas? Otherwise: how can I get the app groovytweets whitelisted? Thanx Sven On Sep 18, 3:21 pm, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina mar...@twitter.com wrote: Asking developers to collapse retweets in timelines is onerous, complicated and confusing. We're not going to do it that way. We are going to add a resource that gives you all retweets for a given tweet. In timelines you will get only the first retweet. You can then request all retweets for that tweet at any time to get up to 100 retweets that have been created for it. Will timelines show if additional retweets exist for each tweet? Otherwise, won't we have to make the request for every tweet to find out if there are others? Nick
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you we're adding statuses/retweets)
Marcel Molina wrote: To give you some ideas of how you can use the API to display retweets, here is a recent mock up of one of the potential UIs for the retweets timeline on twitter.com: http://a1.twimg.com/example-retweet-ui-18-sep-09.png In this example, how did you retrieve the number and names of people that retweeted? Did you have to issue a separate request to statuses/retweets for every single tweet in the timeline? I am concerned about how this affects (mobile) clients on slow and/or expensive connections. Also, how will this interact with the API rate limiting? I would like to present the names and count of all *friends* (people the user is following) that re-tweeted the tweet. This is a much more useful metric than the total number of strangers worldwide that retweeted it (especially when you consider re-tweeting spammers). It seems like this will be impossible if more than 100 people re-tweeted the tweet. The old design was much better in this respect. In particular, now how can we answer the question who do I need to un-follow to stop get this tweet out of my timeline? There's a potentially serious problem with tying the display of the retweet with the first time it is retweeted. Let's say one of your friends (Ae) retweets something on a Friday night. Then a bunch of your friends tweet through the weekend. Then, 50 of your other business associate friends show up for work on Monday and retweet the same thing Ae re-tweeted on Friday night. You will likely not even realize that your business associates are interested in that retweet when you show up for work on Monday, unless you scroll page through all those weekend tweets to the time Ae retweeted them. With the old design, the client could handle this in a much smarter way. Will there be an increase in the API rate limits when this change is made? AFAICT, this new feature increase the number of requests my client makes per refresh substantially for many of my users. The increase in the number of requests seems to be a killer because of rate limiting. I would love to be included as a tester of this in the web UI. I am @BRIAN_ and @GOROGOROmobi. Regards, Brian
