Or, as I think slightly more clearly, perhaps this is an example of
the inconsistency discussed in the OP. Sorry for the noise if that's
the case.
--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com
On May 27, 11:50 am, Ed Finkler wrote:
>
Has this been implemented? I'm getting results that seem to indicate
so. Example:
> curl
> "http://twitter.com/friendships/exists.json?user_a=spaztest&user_b=funkatron";
true
> curl
> "http://twitter.com/friendships/exists.json?user_a=funkatron&user_b=spaztest";
true
so those users are follow
Can I suggest that you add that this value is unused and will be
removed to the API documentation. I have spent quite a while writing
code which I found out wasnt working cos the values are random and
unreliable and then searched around to eventually find this post and
find out it is a problem tha
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.
Doug:
At least we are not expecting this bug to be fixed. So we will have to
go with a peripheral API call. I would have really love to get this in
the same stanza however because, as Dave said very *loudly*, that
makes life much easier for us mobile developers.
Now we will have to wrap this in
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 wrote:
>
> To be blunt this is very unsatisfactory. Once again you guys are no
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
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 the
I'll admit I'm a little disappointed that the info won't be part of
the user objects anymore (will have to rethink some of my planned
features... ie. won't be able to dynamically show/hide the dm button
next to tweets if it means I need an additional api call for each
user) instead relying on anot
