We use JSON thoughout... as JSON and also parsing to db fields... I love that JSON converts directly to OO.... but then again what works for one app, may hinder others... no ideal solution.
I suspect that things will stay as they are anyway... so your our app lose on this one and will just have to do more during our to db parsing operations ... Simon On Oct 7, 7:52 am, Marco Kaiser <kaiser.ma...@gmail.com> wrote: > 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 -- Hide quoted text - > > - Show quoted text -
