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

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!



Subscription settings: 

Reply via email to