On Wed, Sep 16, 2009 at 7:00 AM, Matthew Ranney m...@ranney.com wrote:
Hey Alex, would you consider just giving everybody their money back if they
aren't 100% satisfied?
Hi guys.
I have been developing an iPhone application for push called
notifications : www.appnotifications.com
I've added
I seem to have opened a door that let in something ugly. Apparently
I'm not the only one with concerns but at least I don't have a live
application running that requires constant massaging. I believe my
original question has been answered for now.
Twitter guys: Since I'm currently unemployed I
This.
I've always thought that the obvious path would be to have unique
error codes that never change. So if there's an auth fail it returns
1234 and 1234 corresponds to a specific message that is called
externally. So we send the error code we're getting and it replies
with the message and a
Thanks API team for implementing the cursoring, really needed it
(could you tell!?). I have to go implement that right now.
On Sep 16, 9:24 am, citricsquid s...@samryan.co.uk wrote:
This.
I've always thought that the obvious path would be to have unique
error codes that never change. So if
For applications like yours, moving to the Streaming API will increase
the quality of service for you and decrease load for us. A big part of
building an effective application on our API is figuring out which
methods to use and what strategies to use for retrieving information
and sending updates
On Sep 16, 10:37 am, Alex Payne a...@twitter.com wrote:
Often times, we don't hear from unhappy developers until they're
already outraged and posting on their blogs or in this group. Please:
give us a chance to help you out first. We may not always be able to
make your particular issues our
I completely agree.
As I said, we can't always make someone's pet issue our top priority.
Given that we have basically 2.5 full-time engineers on our team, that
can mean waiting weeks or months for a fix to a lower-priority issue.
But we should absolutely be communicating during that wait, and
On Sep 16, 1:41 pm, Alex Payne a...@twitter.com wrote:
One thing I have noticed, though, is developers going through our user
support track (viahttp://help.twitter.com) rather than contacting the
Platform Team via a...@twitter.com or by filing an issue on our issue
tracker. Our user support
Generally, the folks on the Platform Team aren't set up with accounts
for the user-facing support system. That's why we try to keep things
on the Google Code issue tracker - it's in public, it's easier for our
team to manage, and it's easier for other developers to discover bugs
so we get fewer
WyoKnott,
Thanks for your email. We really appreciate the candid feedback and
definitely is not something we want to see happening. I would like to
hear more about what you mean by not stable enough and what specific
issues we can work on that would get you to consider Twitter a
platform worthy
Ryan, please look no further than existing, accepted issues in the
issues list for examples as to how this platform is not yet ready. One
of your primary API calls, followers/ids (and friends/ids) is broken,
and has been for more than a week now. Since paging is not working,
and un-paged requests
I am only one person with too many irons in the fire. During the month or so that I spent actively working on the Twitter API project I had to go back and change partsmy code more than once, not because of my errors (plenty of those but not the subject of this communication), but because of
Waldron,
We're looking into this issue, but it requires a great deal of
coordination with the folks who work on our back-end infrastructure.
When you ask for a list of denormalized IDs, that request spends very
little time in API code, and most of its time talking to a back-end
system that my
OK Alex, thanks for that insight. I'm trying hard to be patient, but I
hope you can understand that this issue is strangling my new business.
Also, I don't see anything in the documentation which differentiates
these social graph calls from those rising above support on a best-
effort basis. I'm
On Sep 15, 11:04 am, Alex Payne a...@twitter.com wrote:
Please understand that the denormalized lists are currently provided
to developers on a best-effort basis. For the vast majority of Twitter
applications, this data isn't necessary. A specialized class of
applications need this data, and
We're planning on doing just that: communicating more, monitoring the
API via a third-party service from a variety of locales, and providing
better documentation. We've got more developer support hires lined up,
and more.
Thanks for the list of what you'd like to see, and thanks for bearing with
Please also stop willy-nilly changing the error codes and error
messages. Since your error messages are so often inaccurate, some of
us have setup special rules to decipher what the errors actually are
-- when you change the text or code, our rules break.
For example, suspended users are/were
Then maybe mark it in the docs as highly experimental, this way,
people do not build their business plans around something. Make it
clear, this feature could go away at any time.
On Sep 15, 2009, at 11:04 AM, Alex Payne wrote:
Please understand that the denormalized lists are currently
Probably too late for this, but perhaps moving forward, it could be
done...
Twitter.com should move to using their own API. The tools they use to
power their own site should be the same tools we use and rely on.
In all reality, this seems a simpler approach, rather than pushing out
code
: Comments for the group and Twitter staff
Probably too late for this, but perhaps moving forward, it could be
done...
Twitter.com should move to using their own API. The tools they use to
power their own site should be the same tools we use and rely on.
In all reality, this seems a simpler
] Re: Comments for the group and Twitter staff
Probably too late for this, but perhaps moving forward, it could be
done...
Twitter.com should move to using their own API. The tools they use to
power their own site should be the same tools we use and rely on.
In all reality, this seems
: Tuesday, September 15, 2009 5:16 PM
To: twitter-development-talk@googlegroups.com
Subject: [twitter-dev] Re: Comments for the group and Twitter staff
The main twitter.com site already uses the API in some places. Our
revised mobile site is built entirely on the API, and our Facebook
application has
I think the important part here is in some places. The problem is,
twitter.com probably has 75% or more of the exposure. The lowly app
developer hits a bug in the API, and people say wtf, works on
twitter.com, this app sucks.
Good to know that facebook and the mobile site are using the
-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
Haneda
Sent: Tuesday, September 15, 2009 15:55
To: twitter-development-talk@googlegroups.com
Subject: [twitter-dev] Re: Comments for the group and Twitter staff
Probably too late
@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Scott
Haneda
Sent: Tuesday, September 15, 2009 15:55
To: twitter-development-talk@googlegroups.com
Subject: [twitter-dev] Re: Comments for the group and Twitter staff
Probably too late for this, but perhaps moving
25 matches
Mail list logo
