We currently have a number of open defects regarding the "staleness" of various portions of statuses, such as the embedded user objects (e.g. 1378, 1183). We store the entire rendered status, including the user object, and expire it all together as a unit. Therefore, when a user changes his or her information, we do not correctly expire all the statuses and embedded statuses as that is prohibitively expensive. So, this means that the user object rendered in the status is the data as of the time the status for the particular user and format was pulled into cache. The bad news doesn't stop there. The following and notification fields reflect the perspective of the user that caused this object to be pulled into cache -- its probably wrong for you.
This is obviously not good. The solution we're working on right now is a substantial rewrite of the way we render tweets. No new fields will be added, and resilient parsers should see little to no effect. The bad news is that the the ordering of attributes in payloads will change, and will likely break some less resilient parsing code in some application. The worse news is that supporting correct values for the following and notification fields in embedded user objects is likely infeasible given current capacity. We will be setting these to false when rendered embedded in a status. However users/show will still show correct values. To ease the transition we will be providing a preview that will use the new renderer before we push it to production, and we'd love help testing it under normal Twitter load. We'll provide details when we have them, but you will likely be able to access the new renderer by setting a header in your HTTP requests (or, potentially using a different API version in URIs). We'll let it sit in preview for a while, gather feedback, and then roll it out to production. If you have questions/concerns please let us know! ---Mark http://twitter.com/mccv -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
