Retweet is an invasive feature with many deep dependency paths. Firm dates would be useful, but they aren't possible in this particular situation. This makes planning for downstream folks difficult.
I'd be ready for the slight possibility of low-volume retweets mid-to- late week, with a high chance the following week, and perhaps a near- unity chance of low-volume retweets the week after that. So, for critical code, any time now. As for full-roll-out, that would be even more of a guessing game. -John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Oct 4, 6:43 am, Zaudio <si...@z-audio.co.uk> wrote: > Hey John, > > Thanks for that... can you put an earliest date on 'very soon' please > - just so I know how long we've got? > > Thanks > > Simon (Zaudio) > > On Oct 3, 8:15 pm, John Kalucki <jkalu...@gmail.com> wrote: > > > There are plans to filter retweets from various resource, see the > > documentation. However, it would be most prudent to assume that > > retweets will eventually show up everywhere, and handle them > > appropriately, or at least tolerate them wherever they are found. > > > They should start appearing in low volumes in all /1/statuses/* > > resources on the Streaming API very soon. > > > -John Kaluckihttp://twitter.com/jkalucki > > Services, Twitter Inc. > > > On Oct 3, 10:33 am, Zaudio <si...@z-audio.co.uk> wrote: > > > > This sounds a lot more sensible... > > > > Importantly, where can we expect this newpayloadto be returned... > > > any of the following methods as well? > > > > REST API > > > statuses/mentions > > > statuses/user > > > > Streaming API/Shadow > > > > I need to know in advance of such an addition to any of these, as > > > otherwise the parser on one of our apps gets broken until it's recoded > > > to handle theretweetpayload... > > > > or is the ONLY was to get these vie theretweetmethods and the new > > > home_timeline ? If so, what about apps that mainly make use of the > > > Streaming API for tweets? > > > > Thanks > > > > Simon (Zaudio)
