Well, you're not making use of JSON as JSON, and instead use "brute-force" methods to extract parts of it... I think it's a bit unfair to request that change to be made, as it would complicate things for everyone doing "real" JSON-to-OO mapping. Just my 2c.
And no, retweet_status is perfectly valid - it's the property name in a status model, and it is assigned a status data model. Just a nested object. You don't have to name a member "status" just because it is a Status data type... Marco 2009/10/7 Zaudio <si...@z-audio.co.uk> > > Sure, I'll justify this mroe... > > One of our apps receives updates via the Streaming API and the various > REST api methods (mentions, user timelines, friends/home timelines). > We collect data as JSON as it's to date been faster and mor compact > than alternatives... we can also then go on to use this directly > client side in Jscript if we wish... > We are caching all updates of interest in a db... thus parse them for > the required data fields before storing them there. Currently the > parser has to pull out the user node, and is then left with the root > status node.... it is then simple to parse the separated nodes for all > fields pertinant to the current operation. > We make quick checks initially to determine the relevance of the > message to the app's cached stream.... we want to check things like > JUST created_at for the status (and not user) and then check the text > property for certain markers. > It is easy to find these efficiently in a JSON string without parsing > the entire thing to objects as things stand... so we save a lot of > server cpu cycles. It's fastest to this from the inner node > outwards... this is where the 'wasted' cpu cycles are coming in here > with the change for retweeted_status > Status's of interest only have the further fields parsed that we want > for out db copy... > > for example.. say you want to quickly check the id of the status to > confirm if you have it in you db already or not... currently we just > excluded the user node, and thent he id is in the remainder without > conflict. > > Now add retweeted_status with it's user subnode > > To now get the id of the root status without parsing the entire string > to objects... we pull it apart again from the inner node outwards... > we now need to exclude the retweeted_status user subnode... this no > longer has a unique start tag/definition... as there are TWO identical > start tags in the string.... so we do a lot more work to ensure we get > the retweeted_status and it's user node that we would if it had an > alternative start tag. > If it were instead retweeted_user, then we could extract that directly > and easily, exclude it, then exclude the surrounding retweeted_status > tag... and we've got the retweeted_status node separated... then we > can procede as we do now with the rest... and if necessary use the > retweeted_status as well. > > Hope that makes sense.... > I agree that keeping it as user also makes good object sense... but > then the retweeted_status is not 'status' anymore... and it is a > status.... I'm suggesting soemthing similar for it's inner node.. > > Simon (Zaudio) > > > On Oct 6, 12:01 pm, Marco Kaiser <kaiser.ma...@gmail.com> wrote: > > 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 - >
