[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-16 Thread Fabien Penso

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 Gmail push, RSS, Google voice, I provide an API for sending
yourself notifications, and of course I've added Twitter too. I've had
some support from some Twitter developers and I'm happy I did.
However, to reply to the subject of this thread I also had many issues
with the API, some tweets not showing up for example. The complains I
get from users is all about the Twitter plugin I did, I almost regret
to have added it.

I might have done something wrong on my side, but I also have the
feelings, like other people here, than the API is not always working
well. And I don't blame anyone, I think with the number of tweets you
have, and the massive number of new users you had within the last
year, it must be a super exciting job to work at Twitter, but also
such a stressed one :) I wouldn't want to be responsible for
scalability there.

Is there anything we can do to help you guys? Reporting specific bugs
(they are sometimes hard to find and hard to reproduce as it's a
stream).


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-16 Thread WyoKnott

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 might be able to do
some of your grunt work while you address the concerns of other
developers. Is there anything I can do to help?

WK

On Sep 11, 8:36 am, WyoKnott mycro...@lifewithindustry.com wrote:
 A few months ago I was introduced to the Twitter API by a prospective
 client who wanted a custom application. I took the time to learn the
 API and wrote a quick and dirty standalone windows app. The project
 fell through (the client could not get financing) but I have continued
 to be a twitter user and have subscribed to this group email. I
 stopped development on the project because the API does not yet seem
 stable enough for me to try to produce a marketable product on my own
 while at the same time chasing an API around. Is my opinion way off
 the mark or are some of the other developers out there feeling the
 same way.

 I am considering restarting development on the project if the Twitter
 API is likely to get more stable in the near future.

 Thanks for tolerating my ravings

 WyoKnott


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-16 Thread citricsquid

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 description. So say they decide to change auth
fail to auth has failed developers see no changes, unless they're
using the twitter error message and then the message changes. So we
have unique error codes that, when requested, return an error message
that can be changed whenever you guys like and has no affect on
developers and their apps. So for debugging we can simply call the
description and error message from the code, but in a live environment
we can build our own error handling based upon the error code, without
having to constantly watch out for changes.

Apologies if that lacks sense, not very good at explaining.

On Sep 15, 9:21 pm, PJB pjbmancun...@gmail.com wrote:
 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 getting rate limit warnings when
 trying to authenticate as them.  Separately, a new not authorized
 message appears for both failed authentication errors as well as
 successfully authenticated users trying friends/ids on blocking
 users.  Since the messages and codes are the same, it is hard to
 distinguish between these error types to tell the user what is going
 on.  There are about a half-dozen of these ambiguities and bad errors
 that we've accounted for.  (Don't get me started on 200: OK non-
 errors.)

 So, after much trial and error, we CAN figure out the actual
 underlying problem based on the action and message you send us.  But
 when you suddenly change the error code, or message, it throws our
 rules into disarray.

 (Of course, it would be nice if the actual error messages you sent
 were themselves accurate, but for now we're just hoping you can
 CONSISTENTLY send us the same inaccurate errors.)

 On Sep 15, 12:29 pm, Alex Payne a...@twitter.com wrote:

  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 
  us.

  On Tue, Sep 15, 2009 at 12:13, zippy_monster alex.zep...@gmail.com wrote:

   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 doing our best to provide it.

   As a developer, implementation details are mainly a recreational
   interest.  My primary concern is the end result (does it work? or
   not?).  Excuses and apologies are nice, but not a substitute for more
   explicit testing and communication.  So far I've run into two
   disruptive changes:

   - Today, for a brief period, API queries were returning twice the
   number of responses they should have.  Instead of showing the proper 6
   DMs, I was getting 12 back.  Oops.

   - Previously, the way POST + OAuth requests were being handled
   changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
   was sending GET arguments with every request (even POST).  For a while
   this worked, but in the past few weeks this broke with no warning.
   Yeah, that was sloppy client-side code, but the documentation was
   silent on this, and certainly the error message (invalid/re-used
   nonce) was not terribly helpful as a proper nonce was being generated
   each time.

   Additionally, Internet rumblings about how OAuth was handled lend
   credence to the idea that the API just isn't terribly stable... both
   from the idea that you're pushing people to use what is officially
   considered an experimental API, and that it's being treated as an
   experimental API (OAuth specific outages for instance).

   Or, the current pagination problems.  The threads I see here seem to
   all be started by API consumers.  What's missing from the picture is
   an announcement from Twitter that some feature is broken.  That smacks
   of really poor (well, non-existent) communication.

   So, yeah, after spending time tracking down the above problems, and
   reading general internet rumblings, my gut feeling is that the Twitter
   API simply isn't terribly stable.  Specifically, I wonder how serious
   Twitter is about testing things in a non-production environment.  If I
   had to propose a solution, it would be to keep a more explicit list
   (blog, regular group 

[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-16 Thread Waldron Faulkner

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 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 description. So say they decide to change auth
 fail to auth has failed developers see no changes, unless they're
 using the twitter error message and then the message changes. So we
 have unique error codes that, when requested, return an error message
 that can be changed whenever you guys like and has no affect on
 developers and their apps. So for debugging we can simply call the
 description and error message from the code, but in a live environment
 we can build our own error handling based upon the error code, without
 having to constantly watch out for changes.

 Apologies if that lacks sense, not very good at explaining.

 On Sep 15, 9:21 pm, PJB pjbmancun...@gmail.com wrote:

  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 getting rate limit warnings when
  trying to authenticate as them.  Separately, a new not authorized
  message appears for both failed authentication errors as well as
  successfully authenticated users trying friends/ids on blocking
  users.  Since the messages and codes are the same, it is hard to
  distinguish between these error types to tell the user what is going
  on.  There are about a half-dozen of these ambiguities and bad errors
  that we've accounted for.  (Don't get me started on 200: OK non-
  errors.)

  So, after much trial and error, we CAN figure out the actual
  underlying problem based on the action and message you send us.  But
  when you suddenly change the error code, or message, it throws our
  rules into disarray.

  (Of course, it would be nice if the actual error messages you sent
  were themselves accurate, but for now we're just hoping you can
  CONSISTENTLY send us the same inaccurate errors.)

  On Sep 15, 12:29 pm, Alex Payne a...@twitter.com wrote:

   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 us.

   On Tue, Sep 15, 2009 at 12:13, zippy_monster alex.zep...@gmail.com 
   wrote:

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 doing our best to provide it.

As a developer, implementation details are mainly a recreational
interest.  My primary concern is the end result (does it work? or
not?).  Excuses and apologies are nice, but not a substitute for more
explicit testing and communication.  So far I've run into two
disruptive changes:

- Today, for a brief period, API queries were returning twice the
number of responses they should have.  Instead of showing the proper 6
DMs, I was getting 12 back.  Oops.

- Previously, the way POST + OAuth requests were being handled
changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
was sending GET arguments with every request (even POST).  For a while
this worked, but in the past few weeks this broke with no warning.
Yeah, that was sloppy client-side code, but the documentation was
silent on this, and certainly the error message (invalid/re-used
nonce) was not terribly helpful as a proper nonce was being generated
each time.

Additionally, Internet rumblings about how OAuth was handled lend
credence to the idea that the API just isn't terribly stable... both
from the idea that you're pushing people to use what is officially
considered an experimental API, and that it's being treated as an
experimental API (OAuth specific outages for instance).

Or, the current pagination problems.  The threads I see here seem to
all be started by API consumers.  What's missing from the picture is
an announcement from Twitter that some feature is broken.  That smacks
of really poor (well, non-existent) communication.

So, yeah, after spending time tracking down the above problems, and
reading general internet rumblings, my gut feeling is 

[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-16 Thread Alex Payne

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 and direct messages. If you reach out to us
(a...@twitter.com), we're happy to help with that.

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 highest priority, but we'll give it
our best shot. If you're still pissed, then you can go vent :)

And yes, reporting bugs with detailed debugging output (HTTP requests
and responses with all headers and full response bodies) are
incredibly useful. We essentially can't help you without this
information for any non-trivial bugs.

Another huge help to us: if you know anyone who either wants to join
our team as an engineer or help us out with full- or part-time
developer support, please send them to http://twitter.com/jobs. We're
a very small team with a very big job, but we've got the funding to
add more people. Please, please, please send good people our way!
Every addition to the team helps us help you.

On Wed, Sep 16, 2009 at 03:13, Fabien Penso fabienpe...@gmail.com wrote:

 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 Gmail push, RSS, Google voice, I provide an API for sending
 yourself notifications, and of course I've added Twitter too. I've had
 some support from some Twitter developers and I'm happy I did.
 However, to reply to the subject of this thread I also had many issues
 with the API, some tweets not showing up for example. The complains I
 get from users is all about the Twitter plugin I did, I almost regret
 to have added it.

 I might have done something wrong on my side, but I also have the
 feelings, like other people here, than the API is not always working
 well. And I don't blame anyone, I think with the number of tweets you
 have, and the massive number of new users you had within the last
 year, it must be a super exciting job to work at Twitter, but also
 such a stressed one :) I wouldn't want to be responsible for
 scalability there.

 Is there anything we can do to help you guys? Reporting specific bugs
 (they are sometimes hard to find and hard to reproduce as it's a
 stream).




-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-16 Thread zippy_monster

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 highest priority, but we'll give it
 our best shot. If you're still pissed, then you can go vent :)

Well take a look at the grumbling about the OAuth stuff.  Mixed in
with complaints about OAuth are complaints about Twitter support being
non-responsive.  Take a look at this from earlier this month:

http://homeculinaire.blogspot.com/2009/01/twitter-support-your-
problems-are-far.html

That person was waiting two months(!) for a response, only to have his
support tickets deleted.  I suspect a lot of the unhappy bloggers have
indeed tried to contact Twitter, and that this group (and the blogs)
are an outlet of last resort.  Understaffed or not, that sucks for the
developers.


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-16 Thread Alex Payne

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 the
author of that post has every right to be pissed.

One thing I have noticed, though, is developers going through our user
support track (via http://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 folks try their best, but they're often not
able to answer developer questions and are likely to hand that issue
off to our team and close the ticket. Contacting us developer-facing
folks is a much better way to get your issue answered.

On Wed, Sep 16, 2009 at 13:21, zippy_monster alex.zep...@gmail.com wrote:

 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 highest priority, but we'll give it
 our best shot. If you're still pissed, then you can go vent :)

 Well take a look at the grumbling about the OAuth stuff.  Mixed in
 with complaints about OAuth are complaints about Twitter support being
 non-responsive.  Take a look at this from earlier this month:

 http://homeculinaire.blogspot.com/2009/01/twitter-support-your-
 problems-are-far.html

 That person was waiting two months(!) for a response, only to have his
 support tickets deleted.  I suspect a lot of the unhappy bloggers have
 indeed tried to contact Twitter, and that this group (and the blogs)
 are an outlet of last resort.  Understaffed or not, that sucks for the
 developers.




-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-16 Thread zippy_monster

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 folks try their best, but they're often not
 able to answer developer questions and are likely to hand that issue
 off to our team and close the ticket. Contacting us developer-facing
 folks is a much better way to get your issue answered.

Do developers not use or respond to the support tickets directly?

- alex


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-16 Thread Alex Payne

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 duplicates.

On Wed, Sep 16, 2009 at 13:47, zippy_monster alex.zep...@gmail.com wrote:

 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 folks try their best, but they're often not
 able to answer developer questions and are likely to hand that issue
 off to our team and close the ticket. Contacting us developer-facing
 folks is a much better way to get your issue answered.

 Do developers not use or respond to the support tickets directly?

 - alex




-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Ryan Sarver

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 of building your business on.

I look forward to your feedback.

Best, Ryan

On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott mycro...@lifewithindustry.com wrote:

 A few months ago I was introduced to the Twitter API by a prospective
 client who wanted a custom application. I took the time to learn the
 API and wrote a quick and dirty standalone windows app. The project
 fell through (the client could not get financing) but I have continued
 to be a twitter user and have subscribed to this group email. I
 stopped development on the project because the API does not yet seem
 stable enough for me to try to produce a marketable product on my own
 while at the same time chasing an API around. Is my opinion way off
 the mark or are some of the other developers out there feeling the
 same way.

 I am considering restarting development on the project if the Twitter
 API is likely to get more stable in the near future.

 Thanks for tolerating my ravings

 WyoKnott



[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Waldron Faulkner

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 on accounts with many followers yields fail
whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and
it doesn't feel like it's getting any kind of response.

As I have said repeatedly in this forum and in the issues list, this
has frozen business development for my fledgling business, which I
have trusted to the Twitter API. I can't show a broken product. At
some point, you will put this little dream of mine out of business.
I'm up late working on my project, which will ultimately add value to
Twitter's business. I hope your team isn't leaving me high and dry.
Please tell me I don't have to go do a Facebook app instead. Please
tell me that someone was working on this over the weekend.

I'd love to have some solid, no-nonsense response to this, with hard
dates. So far we've had well-meaning but empty words.

Thanks,

- Waldron Faulkner
Founder, GraphEdge LLC.
http://graphedge.com

On Sep 15, 2:59 am, Ryan Sarver rsar...@twitter.com wrote:
 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 of building your business on.

 I look forward to your feedback.

 Best, Ryan

 On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott mycro...@lifewithindustry.com 
 wrote:

  A few months ago I was introduced to the Twitter API by a prospective
  client who wanted a custom application. I took the time to learn the
  API and wrote a quick and dirty standalone windows app. The project
  fell through (the client could not get financing) but I have continued
  to be a twitter user and have subscribed to this group email. I
  stopped development on the project because the API does not yet seem
  stable enough for me to try to produce a marketable product on my own
  while at the same time chasing an API around. Is my opinion way off
  the mark or are some of the other developers out there feeling the
  same way.

  I am considering restarting development on the project if the Twitter
  API is likely to get more stable in the near future.

  Thanks for tolerating my ravings

  WyoKnott


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread mycroftt

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 changes or proposed changes in the API. I would love to be in a position where I could focus exclusvely on this one project but I am not. As well as an ongoing job search I have a couple other projectsshowing promise. I cannot justify more time on Twitter when I see no point where the project graduates from in-development to live and in maintenance mode.


 Original Message Subject: [twitter-dev] Re: Comments for the group and Twitter staffFrom: Ryan Sarver rsar...@twitter.comDate: Mon, September 14, 2009 11:59 pmTo: twitter-development-talk@googlegroups.comWyoKnott,Thanks for your email. We really appreciate the candid feedback anddefinitely is not something we want to see happening. I would like tohear more about what you mean by "not stable enough" and what specificissues we can work on that would get you to consider Twitter aplatform worthy of building your business on.I look forward to your feedback.Best, Ryan


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Alex Payne

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 team has no control over. We're working with the folks
in charge of that on reliability and better ways for developers to
access that data.

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 doing our best to provide it.

On Tue, Sep 15, 2009 at 00:21, Waldron Faulkner
waldronfaulk...@gmail.com wrote:

 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 on accounts with many followers yields fail
 whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and
 it doesn't feel like it's getting any kind of response.

 As I have said repeatedly in this forum and in the issues list, this
 has frozen business development for my fledgling business, which I
 have trusted to the Twitter API. I can't show a broken product. At
 some point, you will put this little dream of mine out of business.
 I'm up late working on my project, which will ultimately add value to
 Twitter's business. I hope your team isn't leaving me high and dry.
 Please tell me I don't have to go do a Facebook app instead. Please
 tell me that someone was working on this over the weekend.

 I'd love to have some solid, no-nonsense response to this, with hard
 dates. So far we've had well-meaning but empty words.

 Thanks,

 - Waldron Faulkner
 Founder, GraphEdge LLC.
 http://graphedge.com

 On Sep 15, 2:59 am, Ryan Sarver rsar...@twitter.com wrote:
 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 of building your business on.

 I look forward to your feedback.

 Best, Ryan

 On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott mycro...@lifewithindustry.com 
 wrote:

  A few months ago I was introduced to the Twitter API by a prospective
  client who wanted a custom application. I took the time to learn the
  API and wrote a quick and dirty standalone windows app. The project
  fell through (the client could not get financing) but I have continued
  to be a twitter user and have subscribed to this group email. I
  stopped development on the project because the API does not yet seem
  stable enough for me to try to produce a marketable product on my own
  while at the same time chasing an API around. Is my opinion way off
  the mark or are some of the other developers out there feeling the
  same way.

  I am considering restarting development on the project if the Twitter
  API is likely to get more stable in the near future.

  Thanks for tolerating my ravings

  WyoKnott




-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Waldron Faulkner

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 not trying to be argumentative, but it would help
me tremendously with prioritization of ongoing development if I knew
which other API calls won't receive priority support if they should
suddenly fail. If there is some internal prioritization, I think the
community needs to know what it is. I know I do!

Thanks,

- Waldron

On Sep 15, 2:04 pm, Alex Payne a...@twitter.com wrote:
 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 team has no control over. We're working with the folks
 in charge of that on reliability and better ways for developers to
 access that data.

 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 doing our best to provide it.

 On Tue, Sep 15, 2009 at 00:21, Waldron Faulkner



 waldronfaulk...@gmail.com wrote:

  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 on accounts with many followers yields fail
  whale, we CANNOT GET LISTS OF FOLLOWERS. That is a major failure, and
  it doesn't feel like it's getting any kind of response.

  As I have said repeatedly in this forum and in the issues list, this
  has frozen business development for my fledgling business, which I
  have trusted to the Twitter API. I can't show a broken product. At
  some point, you will put this little dream of mine out of business.
  I'm up late working on my project, which will ultimately add value to
  Twitter's business. I hope your team isn't leaving me high and dry.
  Please tell me I don't have to go do a Facebook app instead. Please
  tell me that someone was working on this over the weekend.

  I'd love to have some solid, no-nonsense response to this, with hard
  dates. So far we've had well-meaning but empty words.

  Thanks,

  - Waldron Faulkner
  Founder, GraphEdge LLC.
 http://graphedge.com

  On Sep 15, 2:59 am, Ryan Sarver rsar...@twitter.com wrote:
  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 of building your business on.

  I look forward to your feedback.

  Best, Ryan

  On Fri, Sep 11, 2009 at 6:36 AM, WyoKnott mycro...@lifewithindustry.com 
  wrote:

   A few months ago I was introduced to the Twitter API by a prospective
   client who wanted a custom application. I took the time to learn the
   API and wrote a quick and dirty standalone windows app. The project
   fell through (the client could not get financing) but I have continued
   to be a twitter user and have subscribed to this group email. I
   stopped development on the project because the API does not yet seem
   stable enough for me to try to produce a marketable product on my own
   while at the same time chasing an API around. Is my opinion way off
   the mark or are some of the other developers out there feeling the
   same way.

   I am considering restarting development on the project if the Twitter
   API is likely to get more stable in the near future.

   Thanks for tolerating my ravings

   WyoKnott

 --
 Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread zippy_monster

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 doing our best to provide it.

As a developer, implementation details are mainly a recreational
interest.  My primary concern is the end result (does it work? or
not?).  Excuses and apologies are nice, but not a substitute for more
explicit testing and communication.  So far I've run into two
disruptive changes:

- Today, for a brief period, API queries were returning twice the
number of responses they should have.  Instead of showing the proper 6
DMs, I was getting 12 back.  Oops.

- Previously, the way POST + OAuth requests were being handled
changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
was sending GET arguments with every request (even POST).  For a while
this worked, but in the past few weeks this broke with no warning.
Yeah, that was sloppy client-side code, but the documentation was
silent on this, and certainly the error message (invalid/re-used
nonce) was not terribly helpful as a proper nonce was being generated
each time.

Additionally, Internet rumblings about how OAuth was handled lend
credence to the idea that the API just isn't terribly stable... both
from the idea that you're pushing people to use what is officially
considered an experimental API, and that it's being treated as an
experimental API (OAuth specific outages for instance).

Or, the current pagination problems.  The threads I see here seem to
all be started by API consumers.  What's missing from the picture is
an announcement from Twitter that some feature is broken.  That smacks
of really poor (well, non-existent) communication.

So, yeah, after spending time tracking down the above problems, and
reading general internet rumblings, my gut feeling is that the Twitter
API simply isn't terribly stable.  Specifically, I wonder how serious
Twitter is about testing things in a non-production environment.  If I
had to propose a solution, it would be to keep a more explicit list
(blog, regular group postings, whatever) of what changes... even if
you think it's insignificant.  When something breaks, no matter how
small, a formal announcement would be great.  If such a thing exists,
I sure don't know about it.

The API blog hasn't been updated since July.  The third hit on Google
for twitter api is a post to this group begging for documentation.
The API changelog is out there, but it too seems like it's not
consistently updated.


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Alex Payne

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 us.

On Tue, Sep 15, 2009 at 12:13, zippy_monster alex.zep...@gmail.com wrote:

 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 doing our best to provide it.

 As a developer, implementation details are mainly a recreational
 interest.  My primary concern is the end result (does it work? or
 not?).  Excuses and apologies are nice, but not a substitute for more
 explicit testing and communication.  So far I've run into two
 disruptive changes:

 - Today, for a brief period, API queries were returning twice the
 number of responses they should have.  Instead of showing the proper 6
 DMs, I was getting 12 back.  Oops.

 - Previously, the way POST + OAuth requests were being handled
 changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
 was sending GET arguments with every request (even POST).  For a while
 this worked, but in the past few weeks this broke with no warning.
 Yeah, that was sloppy client-side code, but the documentation was
 silent on this, and certainly the error message (invalid/re-used
 nonce) was not terribly helpful as a proper nonce was being generated
 each time.

 Additionally, Internet rumblings about how OAuth was handled lend
 credence to the idea that the API just isn't terribly stable... both
 from the idea that you're pushing people to use what is officially
 considered an experimental API, and that it's being treated as an
 experimental API (OAuth specific outages for instance).

 Or, the current pagination problems.  The threads I see here seem to
 all be started by API consumers.  What's missing from the picture is
 an announcement from Twitter that some feature is broken.  That smacks
 of really poor (well, non-existent) communication.

 So, yeah, after spending time tracking down the above problems, and
 reading general internet rumblings, my gut feeling is that the Twitter
 API simply isn't terribly stable.  Specifically, I wonder how serious
 Twitter is about testing things in a non-production environment.  If I
 had to propose a solution, it would be to keep a more explicit list
 (blog, regular group postings, whatever) of what changes... even if
 you think it's insignificant.  When something breaks, no matter how
 small, a formal announcement would be great.  If such a thing exists,
 I sure don't know about it.

 The API blog hasn't been updated since July.  The third hit on Google
 for twitter api is a post to this group begging for documentation.
 The API changelog is out there, but it too seems like it's not
 consistently updated.




-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread PJB


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 getting rate limit warnings when
trying to authenticate as them.  Separately, a new not authorized
message appears for both failed authentication errors as well as
successfully authenticated users trying friends/ids on blocking
users.  Since the messages and codes are the same, it is hard to
distinguish between these error types to tell the user what is going
on.  There are about a half-dozen of these ambiguities and bad errors
that we've accounted for.  (Don't get me started on 200: OK non-
errors.)

So, after much trial and error, we CAN figure out the actual
underlying problem based on the action and message you send us.  But
when you suddenly change the error code, or message, it throws our
rules into disarray.

(Of course, it would be nice if the actual error messages you sent
were themselves accurate, but for now we're just hoping you can
CONSISTENTLY send us the same inaccurate errors.)


On Sep 15, 12:29 pm, Alex Payne a...@twitter.com wrote:
 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 us.



 On Tue, Sep 15, 2009 at 12:13, zippy_monster alex.zep...@gmail.com wrote:

  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 doing our best to provide it.

  As a developer, implementation details are mainly a recreational
  interest.  My primary concern is the end result (does it work? or
  not?).  Excuses and apologies are nice, but not a substitute for more
  explicit testing and communication.  So far I've run into two
  disruptive changes:

  - Today, for a brief period, API queries were returning twice the
  number of responses they should have.  Instead of showing the proper 6
  DMs, I was getting 12 back.  Oops.

  - Previously, the way POST + OAuth requests were being handled
  changed.  The code I was using (MGTwitterEngine + various OAuth hacks)
  was sending GET arguments with every request (even POST).  For a while
  this worked, but in the past few weeks this broke with no warning.
  Yeah, that was sloppy client-side code, but the documentation was
  silent on this, and certainly the error message (invalid/re-used
  nonce) was not terribly helpful as a proper nonce was being generated
  each time.

  Additionally, Internet rumblings about how OAuth was handled lend
  credence to the idea that the API just isn't terribly stable... both
  from the idea that you're pushing people to use what is officially
  considered an experimental API, and that it's being treated as an
  experimental API (OAuth specific outages for instance).

  Or, the current pagination problems.  The threads I see here seem to
  all be started by API consumers.  What's missing from the picture is
  an announcement from Twitter that some feature is broken.  That smacks
  of really poor (well, non-existent) communication.

  So, yeah, after spending time tracking down the above problems, and
  reading general internet rumblings, my gut feeling is that the Twitter
  API simply isn't terribly stable.  Specifically, I wonder how serious
  Twitter is about testing things in a non-production environment.  If I
  had to propose a solution, it would be to keep a more explicit list
  (blog, regular group postings, whatever) of what changes... even if
  you think it's insignificant.  When something breaks, no matter how
  small, a formal announcement would be great.  If such a thing exists,
  I sure don't know about it.

  The API blog hasn't been updated since July.  The third hit on Google
  for twitter api is a post to this group begging for documentation.
  The API changelog is out there, but it too seems like it's not
  consistently updated.

 --
 Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Scott Haneda


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 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 doing our best to provide it.


--
Scott * If you contact me off list replace talklists@ with scott@ *



[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Scott Haneda


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 for their stuff, and then essentially backporting that to an API,  
just work on making the API, and then integrate that into the  
twitter.com site.


As far as I can tell, this would solve pretty much every problem the  
API has, as there can not be a case where twitter is down, but the API  
is up, or the API is down, and twitter is up.


Twitter should be eating their own dog food :)
--
Scott * If you contact me off list replace talklists@ with scott@ *



[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Jim Renkel

I emphatically second and support the idea of twitter.com having to use
the API.

We had similar quality problems at a place I formerly worked, and they
were solved, completely, when such a policy was instituted.

Yeah, it puts pressure on the API team and may inconvenience the UI
team, or whatever you call them, but in the long run it will be worth
it.

Side effects that we saw were a simpler, cleaner, more consistent
architecture for the whole system, and lower total costs to develop and
maintain the system.

Bite the bullet and do it now. The longer you wait, the more difficult
and expensive it will be. 

Jim Renkel

-Original Message-
From: twitter-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 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 for their stuff, and then essentially backporting that to an API,  
just work on making the API, and then integrate that into the  
twitter.com site.

As far as I can tell, this would solve pretty much every problem the  
API has, as there can not be a case where twitter is down, but the API  
is up, or the API is down, and twitter is up.

Twitter should be eating their own dog food :)
-- 
Scott * If you contact me off list replace talklists@ with scott@ *




[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Alex Payne

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 been built off our API for some time.

Dogfooding! We support it.

On Tue, Sep 15, 2009 at 14:08, Jim Renkel james.ren...@gmail.com wrote:

 I emphatically second and support the idea of twitter.com having to use
 the API.

 We had similar quality problems at a place I formerly worked, and they
 were solved, completely, when such a policy was instituted.

 Yeah, it puts pressure on the API team and may inconvenience the UI
 team, or whatever you call them, but in the long run it will be worth
 it.

 Side effects that we saw were a simpler, cleaner, more consistent
 architecture for the whole system, and lower total costs to develop and
 maintain the system.

 Bite the bullet and do it now. The longer you wait, the more difficult
 and expensive it will be.

 Jim Renkel

 -Original Message-
 From: twitter-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 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 for their stuff, and then essentially backporting that to an API,
 just work on making the API, and then integrate that into the
 twitter.com site.

 As far as I can tell, this would solve pretty much every problem the
 API has, as there can not be a case where twitter is down, but the API
 is up, or the API is down, and twitter is up.

 Twitter should be eating their own dog food :)
 --
 Scott * If you contact me off list replace talklists@ with scott@ *






-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Dean Collins

Hmmm so was does twitter.com work when the API is down.?

How long exactly do you think twitter.com has been using the api for? 

 


-Original Message-
From: twitter-development-talk@googlegroups.com 
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Alex Payne
Sent: 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 been built off our API for some time.

Dogfooding! We support it.

On Tue, Sep 15, 2009 at 14:08, Jim Renkel james.ren...@gmail.com wrote:

 I emphatically second and support the idea of twitter.com having to use
 the API.

 We had similar quality problems at a place I formerly worked, and they
 were solved, completely, when such a policy was instituted.

 Yeah, it puts pressure on the API team and may inconvenience the UI
 team, or whatever you call them, but in the long run it will be worth
 it.

 Side effects that we saw were a simpler, cleaner, more consistent
 architecture for the whole system, and lower total costs to develop and
 maintain the system.

 Bite the bullet and do it now. The longer you wait, the more difficult
 and expensive it will be.

 Jim Renkel

 -Original Message-
 From: twitter-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 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 for their stuff, and then essentially backporting that to an API,
 just work on making the API, and then integrate that into the
 twitter.com site.

 As far as I can tell, this would solve pretty much every problem the
 API has, as there can not be a case where twitter is down, but the API
 is up, or the API is down, and twitter is up.

 Twitter should be eating their own dog food :)
 --
 Scott * If you contact me off list replace talklists@ with scott@ *






-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Scott Haneda


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 API, but  
I suspect that when you say some places, while great news, it needs  
to be all places.


If twitter.com is up, and super app for iphone is not, twitter.com  
gets no heat from that, the developer does.


Thank you for the explanation though.
--
Scott * If you contact me off list replace talklists@ with scott@ *

On Sep 15, 2009, at 2:16 PM, Alex Payne wrote:


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 been built off our API for some time.




[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread PJB


Would be good if Twitter.com used API to determine, e.g., DM count on
right-side.  Right now it is woefully wrong if we delete DMs via API.

On Sep 15, 2:16 pm, Alex Payne a...@twitter.com wrote:
 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 been built off our API for some time.

 Dogfooding! We support it.



 On Tue, Sep 15, 2009 at 14:08, Jim Renkel james.ren...@gmail.com wrote:

  I emphatically second and support the idea of twitter.com having to use
  the API.

  We had similar quality problems at a place I formerly worked, and they
  were solved, completely, when such a policy was instituted.

  Yeah, it puts pressure on the API team and may inconvenience the UI
  team, or whatever you call them, but in the long run it will be worth
  it.

  Side effects that we saw were a simpler, cleaner, more consistent
  architecture for the whole system, and lower total costs to develop and
  maintain the system.

  Bite the bullet and do it now. The longer you wait, the more difficult
  and expensive it will be.

  Jim Renkel

  -Original Message-
  From: twitter-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 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 for their stuff, and then essentially backporting that to an API,
  just work on making the API, and then integrate that into the
  twitter.com site.

  As far as I can tell, this would solve pretty much every problem the
  API has, as there can not be a case where twitter is down, but the API
  is up, or the API is down, and twitter is up.

  Twitter should be eating their own dog food :)
  --
  Scott * If you contact me off list replace talklists@ with scott@ *

 --
 Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x


[twitter-dev] Re: Comments for the group and Twitter staff

2009-09-15 Thread Matthew Ranney
Hey Alex, would you consider just giving everybody their money back if they
aren't 100% satisfied?

On Tue, Sep 15, 2009 at 2:16 PM, Alex Payne a...@twitter.com wrote:


 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 been built off our API for some time.

 Dogfooding! We support it.

 On Tue, Sep 15, 2009 at 14:08, Jim Renkel james.ren...@gmail.com wrote:
 
  I emphatically second and support the idea of twitter.com having to use
  the API.
 
  We had similar quality problems at a place I formerly worked, and they
  were solved, completely, when such a policy was instituted.
 
  Yeah, it puts pressure on the API team and may inconvenience the UI
  team, or whatever you call them, but in the long run it will be worth
  it.
 
  Side effects that we saw were a simpler, cleaner, more consistent
  architecture for the whole system, and lower total costs to develop and
  maintain the system.
 
  Bite the bullet and do it now. The longer you wait, the more difficult
  and expensive it will be.
 
  Jim Renkel
 
  -Original Message-
  From: twitter-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 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 for their stuff, and then essentially backporting that to an API,
  just work on making the API, and then integrate that into the
  twitter.com site.
 
  As far as I can tell, this would solve pretty much every problem the
  API has, as there can not be a case where twitter is down, but the API
  is up, or the API is down, and twitter is up.
 
  Twitter should be eating their own dog food :)
  --
  Scott * If you contact me off list replace talklists@ with scott@ *
 
 
 



 --
 Alex Payne - Platform Lead, Twitter, Inc.
 http://twitter.com/al3x