Something to keep in mind is that when switching from a computer to a mobile device you are losing power/features for mobility. You have to expect the same loss in functionality.
On Mon, May 11, 2009 at 18:38, Dave Mc <davidmccorm...@gmail.com> wrote: > > To be blunt this is very unsatisfactory. Once again you guys are not > being at all cognisant of the requirements of mobile Twitter client > apps. These face much bigger problems than just the rate limit. They > are constrained by physical limitations such as battery life, latency > and bandwidth. And they also have to take account of carrier data > charges. Every time something in your API requires an additional > method call you are making life difficult for us mobile app developers > who are trying to deliver a quality Twitter client to our users (who > are also your users!). > > What annoys me too is that whenever a mobile-specific issue is raised > your stock response is "handle that in a proxy". Guys, that's just not > good enough. The World is going mobile and the continuing development > of your API needs to take account of this. > > Very unhappy about this! > > On May 11, 10:18 pm, Doug Williams <d...@twitter.com> wrote: > > Issues 419 [1] and 474 [2] are very popular, in the painful kind of way. > The > > defects report that methods returning user objects (see users/show for an > > example [3]) are returning incorrect or invalid values for the > <following> > > element. > > > > The fix for this inconsistency is in fact non trivial [4]. The problem > lies > > within the interaction of the application logic, caching layer and > database > > design. The persistent data behind <following> and <notification> values > are > > separate from the user data in our architecture, so to keep these > elements > > valid in cache alongside user objects adds a large amount of complexity. > > > > Developers made it obvious that these data are a priority and we want to > > ensure they available. We also want to guarantee they are accurate and > that > > performance remains good. Given the problems explained above, we are > going > > to be making a number of changes to the API so that you can rely on the > > <following> or <notification> data. > > > > Deprecations: > > The following elements are to be removed from all returned user objects > > returned by the API: > > > > 1) <following> > > 2) <notifications> > > > > This deprecation will not occur until we finish the following: > > > > Additions: > > To continue to provide access to this data we will be creating a new > method: > > > > Issue 532 [4] outlines the need to perform a mutual following lookup. We > > will use a method similar to that described in this issue to deliver > > <following>, <followedby>, <notification> and <pending> (in the case of > > protected users) data with a single call. > > > > We realize this change will cause an increase in API usage for some > > applications. Therefore we are going to increase the default API rate > limit > > across the board. This should help absorb some of the costs for > applications > > attempting to do interesting things with social graph data. The number > will > > be somewhere between 101 and 200 calls but we still need to look at > growth > > projections and current hardware capacity before settling on a definite > > number. > > > > We plan to begin work on this relatively soon with the fix coming in a > few > > weeks. We do not have a planned ship date at this time but will > communicate > > specifics with developers as they are determined. We anticipate the new > > number of calls and a documented schema for the new method will be made > > available before the new method ships. Please watch this thread and > > @twitterapi for the incremental details. > > > > 1.http://code.google.com/p/twitter-api/issues/detail?id=419 > > 2.http://code.google.com/p/twitter-api/issues/detail?id=474 > > 3.http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show > > 4.http://www.jamesshuggins.com/h/tek1/first_computer_bug_large.htm > > 5.http://code.google.com/p/twitter-api/issues/detail?id=532 > > > > Thanks, > > Doug > > -- > > > > Doug Williams > > Twitter Platform Supporthttp://twitter.com/dougw > -- Abraham Williams | http://the.hackerconundrum.com Hacker | http://abrah.am | http://twitter.com/abraham Web608 | Community Evangelist | http://web608.org This email is: [ ] blogable [x] ask first [ ] private.
