Doug,
I appreciate your taking the time to respond to my criticism. I
understand where you're coming from and if I was you I would probably
take the same view. I'm slow to go down the proxy route because this
would require server resources and, like most Twitter clients, my app
is non-commercial. Another issue with use of a proxy is that
Enterprise-managed mobile devices (e.g. BlackBerry devices that use a
BES) are often restricted to a white list of HTTP endpoints. It is
much easier to persuade an admin to allow twitter.com:80 than
proxy.dodgy.com:80.
Hey, here's a cheeky suggestion for Twitter: provide free VM-based
hosting for mobile proxies...
Regards,
Dave.
On May 12, 1:14 am, Doug Williams d...@twitter.com wrote:
David,
As with any solution there are compromises (the normal big three are time,
resources, quality of service) and while this change may make your
particular use of the API more difficult, it is not only important but also
necessary given our architecture and growth. The API provides Twitter data
in a format that is consistent with our strengths. It is up to the consuming
application to make the data we freely provide useful in its independent
context. This decoupling of data and application allows us to focus on data
delivery while the developer attends to user experience. We aim to maximize
performance for board array of use-cases and while at the same time
minimizing operational and maintenance costs.
There are many very successful mobile applications that run a proxy to get
around the resource/time trade-off that this deprecation creates. If you are
mobile heavy, it is suggested you do the same. A proxy is highly recommended
for iPhone apps because it insulates the application changes in the Twitter
API with the App Store acceptance delay.
If anyone has an open source Twitter API proxy, please start another thread
so mobile developers like David do not have to reinvent the wheel. In fact,
there should be a FOSS project for mobile devs to rely on -- I've got a
couple ideas to contribute. Again, please start a thread (and link back
here) if you have code or interest in starting a proxy project.
Thanks,
Doug
--
Doug Williams
Twitter Platform Supporthttp://twitter.com/dougw
On Mon, May 11, 2009 at 4:38 PM, 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
