[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 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 wrote: > On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina 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
[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 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 wrote: > > > On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina 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 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 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 wrote: > > > > On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina 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'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 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 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 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 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 wrote: > > > > > On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina > > > > 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 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 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 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 wrote: > > > > > On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina > > > > 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 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 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 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 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 wrote: > > > > > > On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina > > > > > 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 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 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 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 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 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 wrote: > > > > > > > On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina > > > > > > 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 >
[twitter-dev] Re: Update on the Retweet API (we collapse retweets, not you & we're adding statuses/retweets)
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 wrote: > Thanx, I'll give that a try. > > On Sep 23, 8:11 pm, John Kalucki 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 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 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 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 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 wrote: > > > > > > > > On Fri, Sep 18, 2009 at 1:57 PM, Marcel Molina > > > > > > > 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 g
[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 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 wrote: > > > Thanx, I'll give that a try. > > > On Sep 23, 8:11 pm, John Kalucki 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 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 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 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 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 > > > > >
[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 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 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 wrote: > > > > Thanx, I'll give that a try. > > > > On Sep 23, 8:11 pm, John Kalucki 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 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 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 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 anyo
