Thanks, Matt! I've added the information from my mail as a comment to that issue.
Marco 2009/4/21 Matt Sanford <m...@twitter.com> > Hi there, > > This sounds like it is related to Google Code issue 474 [1]. Please visit > Google Code and click on the little star next to the title to get updates > when that issue is updated. > Thanks; > — Matt Sanford > > [1] - http://code.google.com/p/twitter-api/issues/detail?id=474 > > On Apr 21, 2009, at 04:22 AM, Marco Kaiser wrote: > > Doug? Anyone? > > Thanks, > Marco > > 2009/4/9 Marco Kaiser <kaiser.ma...@gmail.com> > >> I recognize an odd behavior for the "following" property of embedded user >> object in the friends timeline (XML format). As I understand from the API >> docs, "following" should indicate whether the authenticating user is >> following the returned user. >> >> Obviously, all tweets returned on the /statuses/friends_timeline.xml >> endpoint should come from users I am following (and I manually verified that >> for some samples), but still some of them have <following>false</following> >> set. It seems to be at least consistant in a way that the same user always >> has the same value set for following in a result set - it just is either >> always wrong or always right. >> >> Is that a known issue? >> >> Thanks, >> Marco >> >> 2009/4/5 Martin Dufort <martin.duf...@gmail.com> >> >> >>> I'm seeing inconsitent user attributes within the *same* request for >>> the *same* user. One result has full attributes disclosure, and the >>> other one has not. >>> >>> I've updated Issue 409 with my results. >>> Martin >>> >>> On Apr 2, 8:36 pm, Doug Williams <d...@twitter.com> wrote: >>> > Jeffery, >>> > This is valid criticism. This bug came as a surprise to us as well. We >>> > otherwise would have given developers fair warning. Unfortunately there >>> is >>> > no easy fix, and like a bad heart-break, time may be the only answer. >>> > >>> > In short, the problem is with the user data cache. To get the extended >>> > information into that cache, the user object must either expire or be >>> > invalidated through some user initiated update. The expiry on the cache >>> is >>> > rather long and you will find that inactive accounts will have >>> abbreviated >>> > data for up to 2 weeks. >>> > >>> > This is obviously sub-optimal, as Matt would say. >>> > >>> > Doug Williams >>> > Twitter API Supporthttp://twitter.com/dougw >>> > >>> > On Thu, Apr 2, 2009 at 12:27 PM, Jeffrey Greenberg < >>> > >>> > >>> > >>> > jeffreygreenb...@gmail.com> wrote: >>> > >>> > > Doug, >>> > > Grumble: just to say it, this wasn't handled well at all. The fact >>> > > that this field disappears whether due to caching or through a coding >>> > > error has the same result of completely breaking my app. >>> > >>> > > How long will it take for this issue to clear up? Days? How many >>> > > exactly? and after X days will further requests be populated >>> > > correctly? >>> > >>> > > thx, >>> > > jeffrey >>> > >http://www.tweettronics.com >>> >> >> > >
