No, please don't change that to retweeted_user ... the data structure included as the retweeted status is a status, and that data structure has a user property. That's a very clear object model, and should map very well to JSON, as it's nested, not at the same level as the main user the retweet is received from. So by doing that change, you'd break the data model for a status, in that there are two version that need to be taken care of.
Or can you explain in more depth why this would cause problems with reasonable JSON parsers that map strings to objects? 2009/10/6 Zaudio <si...@z-audio.co.uk> > > Another significant thought... could you 'please' consider changing > the name of the <user> node INSIDE the retweeted_status node to say > <retweeted_user> ? > > Thius will make JSON parsing way simpler... especially if the goal is > to extract the retweeted_status when present; or do things like > quickly find the date of the tweet... I alreayd have to contend with a > created_at field in the user and status nodes... now that could double > up... so owuld appreciate an easier to find retweeted user node for > JSON parsability > > Thanks > > Simon (Zaudio) > > On Oct 4, 8:16 am, John Kalucki <jkalu...@gmail.com> wrote: > > Retweetis 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 Kaluckihttp://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)- Hide quoted text - > > > > - Show quoted text -
