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

[Fabien Penso]

On Wed, Sep 16, 2009 at 7:00 AM, Matthew Ranney  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

[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  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] What constitutes an "update"?

[Craig Wistow]

Hi Everyone,

I'm busy developing a system that uses the Twitter API and i'd like to
know what Twitter classes as an "update"?

Following a user? Retrieving direct messages? Replying to a direct
message? etc

The reason I ask is because I want to count each update that the
system makes so that I can ensure it stays below the limit of 1,000
updates per day.

Thanks in advance,

Craig

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

[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  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  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  wrote:
>
> > > On Sep 15, 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.
>
> > > 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 p

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

[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  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  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  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  
> > > wrote:
>
> > > > On Sep 15, 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.
>
> > > > 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) communicat

[twitter-dev] Have tweet ID, need the URL prefix

[Joseph]

If I have a tweet ID, how do I access the tweet using a url. I'm
assuming there's an http://www.twitter.com//1234567890?

[twitter-dev] Re: Have tweet ID, need the URL prefix

[shiplu]

On Wed, Sep 16, 2009 at 10:58 AM, Joseph  wrote:
>
> If I have a tweet ID, how do I access the tweet using a url. I'm
> assuming there's an http://www.twitter.com//1234567890?

http://twitter.com/USERNAME/status/TWEET_ID


-- 
A K M Mokaddim
http://talk.cmyweb.net
http://twitter.com/shiplu
Stop Top Posting !!
বাংলিশ লেখার চাইতে বাংলা লেখা অনেক ভাল
Sent from Dhaka, Bangladesh

[twitter-dev] statuses/mentions vs search/screenname

[Joseph Cheek]

Quick q:

is there any time that a search for a screenname won't return every
tweet that statuses/mentions will?  i can see that it would return more,
but will it ever return less?

 
Joseph Cheek
jos...@cheek.com, www.cheek.com
twitter: http://twitter.com/cheekdotcom

[twitter-dev] Re: statuses/mentions vs search/screenname

[JDG]

I believe that search does not return statuses of protected users (even when
authenticated, though I may be wrong and should be corrected if I am). In
that case, yes, you could potentially receive fewer results than
statuses/mentions.

On Wed, Sep 16, 2009 at 09:56, Joseph Cheek  wrote:

>
> Quick q:
>
> is there any time that a search for a screenname won't return every
> tweet that statuses/mentions will?  i can see that it would return more,
> but will it ever return less?
>
>
> Joseph Cheek
> jos...@cheek.com, www.cheek.com
> twitter: http://twitter.com/cheekdotcom
>
>


-- 
Internets. Serious business.

[twitter-dev] Re: non json response

[Naveen A]

Is there a specific way we can construct our request to mitigate the
non-json response? I have used a few different twitter clients on the
same mobile device and some of them do not seem to be plagued with the
bad data like we are? Does including something in the header help get
us through whatever filter is returning the bad data?

Maybe the Twitter cookies that are returned back on each request?
Currently, we don't pass them back on subsequent requests because they
shouldn't be necessary, but if it will make some of the bad JSON
responses go away, I'll spend the time to implement it..

These bad json responses have been a problem for over a month now and
while I realize it is a difficult problem to track down, the fact
remains that the API is not functioning correctly.

A response from the twitter team would be greatly appreciated.


On Sep 13, 6:01 am, Rudifa  wrote:
> I just had one non-json response, in the middle of about 10 requests
> made with curl -vvv (other responses were correct)
>
> Below are 3 requests and the non-json response bracketted by 2 good
> responses which contain the response time and other logging data.
>
> HTH
> Rudi
>
> rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl 
> -vvvhttp://twitter.com/users/show/rudifa.json
> * About to connect() to twitter.com port 80 (#0)
> *   Trying 168.143.161.20... connected
> * Connected to twitter.com (168.143.161.20) port 80 (#0)> GET 
> /users/show/rudifa.json HTTP/1.1
> > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 
> > OpenSSL/0.9.7l zlib/1.2.3
> > Host: twitter.com
> > Accept: */*
>
> < HTTP/1.1 200 OK
> < Date: Sun, 13 Sep 2009 09:45:23 GMT
> < Server: hi
> < X-RateLimit-Limit: 150
> < X-Transaction: 1252835123-2408-31139
> < Status: 200 OK
> < ETag: "df090f6c8147e20ba7fe81315a66b9af"
> < Last-Modified: Sun, 13 Sep 2009 09:45:23 GMT
> < X-RateLimit-Remaining: 124
> < Content-Type: application/json; charset=utf-8
> < Pragma: no-cache
> < Content-Length: 1176
> < Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,
> post-check=0
> < Expires: Tue, 31 Mar 1981 05:00:00 GMT
> < X-Revision: a62881015b2c2fb6f795bf931bd56bd494f37254
> < X-RateLimit-Reset: 1252836853
> < Set-Cookie: lang=en; path=/
> < Set-Cookie:
> _twitter_sess=BAh7CDoRdHJhbnNfcHJvbXB0MDoHaWQiJWU5OGQyZmU3NWVkY2RhZjhkYTk5% 
> 250ANTBlNTA4OTk0MzhhIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFz
> %250AaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA--66931156c75554797fc576876bdec52dc705 
> 736e;
> domain=.twitter.com; path=/
> < Vary: Accept-Encoding
> < Connection: close
> <
> * Closing connection #0
> {"profile_sidebar_border_color":"BDDCAD","description":"Wrote firmware
> for world-class osciloscopes for many years. Now learning iPhone
> programming tricks. Loves
> skiing.","url":null,"screen_name":"rudifa","status":
> {"in_reply_to_status_id":null,"favorited":false,"in_reply_to_user_id":null, 
> "source":" href=\"http://apiwiki.twitter.com/\"; rel=\"nofollow\">API a>","created_at":"Thu Sep 10 16:49:49 +
> 2009","in_reply_to_screen_name":null,"id":
> 3890997267,"truncated":false,"text":"De retour de la T\u00eate de
> Parmelan"},"following":null,"verified":false,"profile_text_color":"33", 
> "followers_count":
> 9,"profile_background_image_url":"http://a1.twimg.com/
> profile_background_images/17762518/
> DSC01211-63-2.jpeg","created_at":"Thu Apr 30 22:42:35 +
> 2009","notifications":null,"friends_count":
> 29,"profile_link_color":"0084B4","profile_background_tile":false,"favourite 
> s_count":
> 0,"profile_background_color":"9AE4E8","protected":false,"time_zone":"Bern", 
> "location":"Geneva","name":"Rudi
> Farkas","profile_sidebar_fill_color":"DDFFCC","id":
> 36797542,"statuses_count":52,"utc_offset":
> 3600,"profile_image_url":"http://a1.twimg.com/profile_images/311858510/
> me-bsp-6a_normal.png"}
>
> rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl 
> -vvvhttp://twitter.com/users/show/rudifa.json
> * About to connect() to twitter.com port 80 (#0)
> *   Trying 168.143.161.20... connected
> * Connected to twitter.com (168.143.161.20) port 80 (#0)> GET 
> /users/show/rudifa.json HTTP/1.1
> > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 
> > OpenSSL/0.9.7l zlib/1.2.3
> > Host: twitter.com
> > Accept: */*
>
> < HTTP/1.0 200 OK
> < Connection: Close
> < Pragma: no-cache
> < cache-control: no-cache
> < Refresh: 0.1
> < Content-Type: text/html; charset=iso-8859-1
> <
> http://www.w3.org/
> TR/1999/REC-html401-19991224/strict.dtd">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> * Closing connection #0
>
> rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl 
> -vvvhttp://twitter.com/users/show/rudifa.json
> * About to connect() to twitter.com port 80 (#0)
> *   Trying 168.143.161.20... connected
> * Connected to twitter.com (168.143.161.20) port 80 (#0)> GET 
> /users/show/rudifa.json HTTP/1.1
> > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 
> > OpenSSL/0.9.7l zlib/1.2.3
> > Host: twitter.com
> > Accept: */*
>
> < HTTP

[twitter-dev] Re: statuses/mentions vs search/screenname

[Hwee-Boon Yar]

Along the same line, updates from accounts considered spamming
wouldn't be included in search results too.

--
Hwee-Boon

On Sep 17, 12:07 am, JDG  wrote:
> I believe that search does not return statuses of protected users (even when
> authenticated, though I may be wrong and should be corrected if I am). In
> that case, yes, you could potentially receive fewer results than
> statuses/mentions.
>
> On Wed, Sep 16, 2009 at 09:56, Joseph Cheek  wrote:
>
> > Quick q:
>
> > is there any time that a search for a screenname won't return every
> > tweet that statuses/mentions will?  i can see that it would return more,
> > but will it ever return less?
>
> > Joseph Cheek
> > jos...@cheek.com,www.cheek.com
> > twitter:http://twitter.com/cheekdotcom
>
> --
> Internets. Serious business.

[twitter-dev] Re: statuses/mentions vs search/screenname

[Joseph Cheek]

so statuses/mentions will retrieve mentions from protected users'
timelines, even if you are not authorized to see them?

Joseph

JDG wrote:
> I believe that search does not return statuses of protected users
> (even when authenticated, though I may be wrong and should be
> corrected if I am). In that case, yes, you could potentially receive
> fewer results than statuses/mentions.
>
> On Wed, Sep 16, 2009 at 09:56, Joseph Cheek  > wrote:
>
>
> Quick q:
>
> is there any time that a search for a screenname won't return every
> tweet that statuses/mentions will?  i can see that it would return
> more,
> but will it ever return less?
>
>
> Joseph Cheek
> jos...@cheek.com , www.cheek.com
> 
> twitter: http://twitter.com/cheekdotcom
>
>
>
>
> -- 
> Internets. Serious business.

-- 
Joseph Cheek
jos...@cheek.com, www.cheek.com
twitter: http://twitter.com/cheekdotcom

[twitter-dev] Re: statuses/mentions vs search/screenname

[Joseph Cheek]

will they be included in statuses/mentions?

Joseph

Hwee-Boon Yar wrote:
> Along the same line, updates from accounts considered spamming
> wouldn't be included in search results too.
>
> --
> Hwee-Boon
>
> On Sep 17, 12:07 am, JDG  wrote:
>   
>> I believe that search does not return statuses of protected users (even when
>> authenticated, though I may be wrong and should be corrected if I am). In
>> that case, yes, you could potentially receive fewer results than
>> statuses/mentions.
>>
>> On Wed, Sep 16, 2009 at 09:56, Joseph Cheek  wrote:
>>
>> 
>>> Quick q:
>>>   
>>> is there any time that a search for a screenname won't return every
>>> tweet that statuses/mentions will?  i can see that it would return more,
>>> but will it ever return less?
>>>   
>>> Joseph Cheek
>>> jos...@cheek.com,www.cheek.com
>>> twitter:http://twitter.com/cheekdotcom
>>>   
>> --
>> Internets. Serious business.
>> 
>
>   

-- 
Joseph Cheek
jos...@cheek.com, www.cheek.com
twitter: http://twitter.com/cheekdotcom

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

[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  wrote:
>
> On Wed, Sep 16, 2009 at 7:00 AM, Matthew Ranney  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: non json response

[Raffi Krikorian]

hi naveen.

we are most certainly working on it.

the best way to mitigate the error case is to actually do what the  
response tells you to do -- in all cases that i've seen the "http 200  
error", there has been a refresh header ("Refresh: 0.1").  simply obey  
the header, make a subsequent request in 0.1 seconds, and more likely  
than not, you will receive your request.  in general, "be strict in  
what you send out, and be lenient in what you accept" is a pretty good  
philosophy to follow.  an additional strategy to try: if you receive  
an error, then try again with some form of exponential back-off.


if you do see the error, please either send me, personally, a tcpdump  
of the issue, or attach it to the issue on http://code.google.com/p/twitter-api/issues/detail?id=1024 
.


thanks!


Is there a specific way we can construct our request to mitigate the
non-json response? I have used a few different twitter clients on the
same mobile device and some of them do not seem to be plagued with the
bad data like we are? Does including something in the header help get
us through whatever filter is returning the bad data?

Maybe the Twitter cookies that are returned back on each request?
Currently, we don't pass them back on subsequent requests because they
shouldn't be necessary, but if it will make some of the bad JSON
responses go away, I'll spend the time to implement it..

These bad json responses have been a problem for over a month now and
while I realize it is a difficult problem to track down, the fact
remains that the API is not functioning correctly.

A response from the twitter team would be greatly appreciated.


On Sep 13, 6:01 am, Rudifa  wrote:

I just had one non-json response, in the middle of about 10 requests
made with curl -vvv (other responses were correct)

Below are 3 requests and the non-json response bracketted by 2 good
responses which contain the response time and other logging data.

HTH
Rudi

rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl 
-vvvhttp://twitter.com/users/show/rudifa.json
* About to connect() to twitter.com port 80 (#0)
*   Trying 168.143.161.20... connected
* Connected to twitter.com (168.143.161.20) port 80 (#0)> GET / 
users/show/rudifa.json HTTP/1.1
User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3  
OpenSSL/0.9.7l zlib/1.2.3

Host: twitter.com
Accept: */*


< HTTP/1.1 200 OK
< Date: Sun, 13 Sep 2009 09:45:23 GMT
< Server: hi
< X-RateLimit-Limit: 150
< X-Transaction: 1252835123-2408-31139
< Status: 200 OK
< ETag: "df090f6c8147e20ba7fe81315a66b9af"
< Last-Modified: Sun, 13 Sep 2009 09:45:23 GMT
< X-RateLimit-Remaining: 124
< Content-Type: application/json; charset=utf-8
< Pragma: no-cache
< Content-Length: 1176
< Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,
post-check=0
< Expires: Tue, 31 Mar 1981 05:00:00 GMT
< X-Revision: a62881015b2c2fb6f795bf931bd56bd494f37254
< X-RateLimit-Reset: 1252836853
< Set-Cookie: lang=en; path=/
< Set-Cookie:
_twitter_sess 
=BAh7CDoRdHJhbnNfcHJvbXB0MDoHaWQiJWU5OGQyZmU3NWVkY2RhZjhkYTk5%  
250ANTBlNTA4OTk0MzhhIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFz
%250AaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA 
--66931156c75554797fc576876bdec52dc705 736e;

domain=.twitter.com; path=/
< Vary: Accept-Encoding
< Connection: close
<
* Closing connection #0
{"profile_sidebar_border_color":"BDDCAD","description":"Wrote  
firmware

for world-class osciloscopes for many years. Now learning iPhone
programming tricks. Loves
skiing.","url":null,"screen_name":"rudifa","status":
{"in_reply_to_status_id 
":null,"favorited":false,"in_reply_to_user_id":null, "source":"
href=\"http://apiwiki.twitter.com/\"; rel=\"nofollow\">API","created_at":"Thu Sep 10 16:49:49 +
2009","in_reply_to_screen_name":null,"id":
3890997267,"truncated":false,"text":"De retour de la T\u00eate de
Parmelan 
"},"following":null,"verified":false,"profile_text_color":"33",  
"followers_count":

9,"profile_background_image_url":"http://a1.twimg.com/
profile_background_images/17762518/
DSC01211-63-2.jpeg","created_at":"Thu Apr 30 22:42:35 +
2009","notifications":null,"friends_count":
29 
,"profile_link_color 
":"0084B4","profile_background_tile":false,"favourite s_count":
0 
,"profile_background_color 
":"9AE4E8","protected":false,"time_zone":"Bern",  
"location":"Geneva","name":"Rudi

Farkas","profile_sidebar_fill_color":"DDFFCC","id":
36797542,"statuses_count":52,"utc_offset":
3600,"profile_image_url":"http://a1.twimg.com/profile_images/311858510/
me-bsp-6a_normal.png"}

rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl 
-vvvhttp://twitter.com/users/show/rudifa.json
* About to connect() to twitter.com port 80 (#0)
*   Trying 168.143.161.20... connected
* Connected to twitter.com (168.143.161.20) port 80 (#0)> GET / 
users/show/rudifa.json HTTP/1.1
User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3  
OpenSSL/0.9.7l zlib/1.2.3

Host: twitter.com
Accept: */*


< HTTP/1.0 200 OK
< Connection: Close
< Pragma: no-cache
< cache-con

[twitter-dev] Re: non json response

[John Kalucki]

I've been following the internal dialog on tracking this issue down.
Given what we know, I don't think there's anything that you can change
to the request parameters to reduce the chances of this happening.
>From a given client, the chances of this happening to a request are
pretty close to random. Different clients, however, seem from the
outside to operate differently, as they tend to routed through
different infrastructure. There also may be differences in the quality
of the code, especially around how errors are handled.

If you want higher reliability,  I'd suggest wrapping nearly all
network API calls in a retry loop. If you get any sort of error: tcp,
http, parser, etc. retry with linear backoff.

-John Kalucki
http://twitter.com/jkalucki
Services, Twitter Inc.


On Sep 16, 10:23 am, Naveen A  wrote:
> Is there a specific way we can construct our request to mitigate the
> non-json response? I have used a few different twitter clients on the
> same mobile device and some of them do not seem to be plagued with the
> bad data like we are? Does including something in the header help get
> us through whatever filter is returning the bad data?
>
> Maybe the Twitter cookies that are returned back on each request?
> Currently, we don't pass them back on subsequent requests because they
> shouldn't be necessary, but if it will make some of the bad JSON
> responses go away, I'll spend the time to implement it..
>
> These bad json responses have been a problem for over a month now and
> while I realize it is a difficult problem to track down, the fact
> remains that the API is not functioning correctly.
>
> A response from the twitter team would be greatly appreciated.
>
> On Sep 13, 6:01 am, Rudifa  wrote:
>
> > I just had one non-json response, in the middle of about 10 requests
> > made with curl -vvv (other responses were correct)
>
> > Below are 3 requests and the non-json response bracketted by 2 good
> > responses which contain the response time and other logging data.
>
> > HTH
> > Rudi
>
> > rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl 
> > -vvvhttp://twitter.com/users/show/rudifa.json
> > * About to connect() to twitter.com port 80 (#0)
> > *   Trying 168.143.161.20... connected
> > * Connected to twitter.com (168.143.161.20) port 80 (#0)> GET 
> > /users/show/rudifa.json HTTP/1.1
> > > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 
> > > OpenSSL/0.9.7l zlib/1.2.3
> > > Host: twitter.com
> > > Accept: */*
>
> > < HTTP/1.1 200 OK
> > < Date: Sun, 13 Sep 2009 09:45:23 GMT
> > < Server: hi
> > < X-RateLimit-Limit: 150
> > < X-Transaction: 1252835123-2408-31139
> > < Status: 200 OK
> > < ETag: "df090f6c8147e20ba7fe81315a66b9af"
> > < Last-Modified: Sun, 13 Sep 2009 09:45:23 GMT
> > < X-RateLimit-Remaining: 124
> > < Content-Type: application/json; charset=utf-8
> > < Pragma: no-cache
> > < Content-Length: 1176
> > < Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,
> > post-check=0
> > < Expires: Tue, 31 Mar 1981 05:00:00 GMT
> > < X-Revision: a62881015b2c2fb6f795bf931bd56bd494f37254
> > < X-RateLimit-Reset: 1252836853
> > < Set-Cookie: lang=en; path=/
> > < Set-Cookie:
> > _twitter_sess=BAh7CDoRdHJhbnNfcHJvbXB0MDoHaWQiJWU5OGQyZmU3NWVkY2RhZjhkYTk5% 
> > 250ANTBlNTA4OTk0MzhhIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFz
> > %250AaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA--66931156c75554797fc576876bdec52dc705 
> > 736e;
> > domain=.twitter.com; path=/
> > < Vary: Accept-Encoding
> > < Connection: close
> > <
> > * Closing connection #0
> > {"profile_sidebar_border_color":"BDDCAD","description":"Wrote firmware
> > for world-class osciloscopes for many years. Now learning iPhone
> > programming tricks. Loves
> > skiing.","url":null,"screen_name":"rudifa","status":
> > {"in_reply_to_status_id":null,"favorited":false,"in_reply_to_user_id":null, 
> > "source":" > href=\"http://apiwiki.twitter.com/\"; rel=\"nofollow\">API > a>","created_at":"Thu Sep 10 16:49:49 +
> > 2009","in_reply_to_screen_name":null,"id":
> > 3890997267,"truncated":false,"text":"De retour de la T\u00eate de
> > Parmelan"},"following":null,"verified":false,"profile_text_color":"33", 
> > "followers_count":
> > 9,"profile_background_image_url":"http://a1.twimg.com/
> > profile_background_images/17762518/
> > DSC01211-63-2.jpeg","created_at":"Thu Apr 30 22:42:35 +
> > 2009","notifications":null,"friends_count":
> > 29,"profile_link_color":"0084B4","profile_background_tile":false,"favourite 
> > s_count":
> > 0,"profile_background_color":"9AE4E8","protected":false,"time_zone":"Bern", 
> > "location":"Geneva","name":"Rudi
> > Farkas","profile_sidebar_fill_color":"DDFFCC","id":
> > 36797542,"statuses_count":52,"utc_offset":
> > 3600,"profile_image_url":"http://a1.twimg.com/profile_images/311858510/
> > me-bsp-6a_normal.png"}
>
> > rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl 
> > -vvvhttp://twitter.com/users/show/rudifa.json
> > * About to connect() to twitter.com port 80 (#0)
> > *   Trying 1

[twitter-dev] Re: statuses/mentions vs search/screenname

[JDG]

Those will, so long as they haven't actually been suspended. As for your
other question, you would only receive mentions from protected accounts that
you were following (i.e. accounts to which you had access).

On Wed, Sep 16, 2009 at 11:35, Joseph Cheek  wrote:

>
> will they be included in statuses/mentions?
>
> Joseph
>
> Hwee-Boon Yar wrote:
> > Along the same line, updates from accounts considered spamming
> > wouldn't be included in search results too.
> >
> > --
> > Hwee-Boon
> >
> > On Sep 17, 12:07 am, JDG  wrote:
> >
> >> I believe that search does not return statuses of protected users (even
> when
> >> authenticated, though I may be wrong and should be corrected if I am).
> In
> >> that case, yes, you could potentially receive fewer results than
> >> statuses/mentions.
> >>
> >> On Wed, Sep 16, 2009 at 09:56, Joseph Cheek  wrote:
> >>
> >>
> >>> Quick q:
> >>>
> >>> is there any time that a search for a screenname won't return every
> >>> tweet that statuses/mentions will?  i can see that it would return
> more,
> >>> but will it ever return less?
> >>>
> >>> Joseph Cheek
> >>> jos...@cheek.com,www.cheek.com
> >>> twitter:http://twitter.com/cheekdotcom
> >>>
> >> --
> >> Internets. Serious business.
> >>
> >
> >
>
> --
> Joseph Cheek
> jos...@cheek.com, www.cheek.com
> twitter: http://twitter.com/cheekdotcom
>
>


-- 
Internets. Serious business.

[twitter-dev] Re: statuses/mentions vs search/screenname

[Joseph Cheek]

thanks - i'll change my client code!

Joseph Cheek
jos...@cheek.com, www.cheek.com
twitter: http://twitter.com/cheekdotcom



JDG wrote:
> Those will, so long as they haven't actually been suspended. As for
> your other question, you would only receive mentions from protected
> accounts that you were following (i.e. accounts to which you had access).
>
> On Wed, Sep 16, 2009 at 11:35, Joseph Cheek  > wrote:
>
>
> will they be included in statuses/mentions?
>
> Joseph
>
> Hwee-Boon Yar wrote:
> > Along the same line, updates from accounts considered spamming
> > wouldn't be included in search results too.
> >
> > --
> > Hwee-Boon
> >
> > On Sep 17, 12:07 am, JDG  > wrote:
> >
> >> I believe that search does not return statuses of protected
> users (even when
> >> authenticated, though I may be wrong and should be corrected if
> I am). In
> >> that case, yes, you could potentially receive fewer results than
> >> statuses/mentions.
> >>
> >> On Wed, Sep 16, 2009 at 09:56, Joseph Cheek  > wrote:
> >>
> >>
> >>> Quick q:
> >>>
> >>> is there any time that a search for a screenname won't return
> every
> >>> tweet that statuses/mentions will?  i can see that it would
> return more,
> >>> but will it ever return less?
> >>>
>
>

[twitter-dev] 403 and 503 errors from search API

[Michael Paladino]

Anyone else noticing more error messages than normal from the search API?
I'm getting quite a few 403 Forbidden and 503 Server Unavailable errors.  I
looked for the "Retry-After" that would indicate rate limiting and don't see
it.  Thoughts?

 

Thanks.

 

Michael Paladino

  http://tidytweet.com

 

 

 

 

[twitter-dev] Re: non json response

[Jim Renkel]

I agree with John that to achieve higher user visible reliability, API
requests should be wrapped in a retry loop.

However, PLEASE, PLEASE, PLEASE, do NOT use linear backoff, i.e.,
subsequent retries are delayed by an amount of time chosen uniformly at
random up to the same maximum amount for each retry. This will lead to
disasters for all API users as failed API requests, when retried, will
tend to bunch up in ever increasing bunches, leading to a higher, not
lower, failure rate.

You should instead use exponential backoff, where the maximum amount of
delay time increases for each retry. Queuing theory and experience
indicate that the optimum factor used to increase the maximum delay for
each retry should be 2.0.

The earliest implementations of both Ethernet and TCP, and I'm sure
other protocols, tried linear backoff and experienced this problem in
spades. When the backoff was changed to exponential, the problems
miraculously went away.

Jim Renkel

-Original Message-
From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of John
Kalucki
Sent: Wednesday, September 16, 2009 12:56
To: Twitter Development Talk
Subject: [twitter-dev] Re: non json response


I've been following the internal dialog on tracking this issue down.
Given what we know, I don't think there's anything that you can change
to the request parameters to reduce the chances of this happening.
>From a given client, the chances of this happening to a request are
pretty close to random. Different clients, however, seem from the
outside to operate differently, as they tend to routed through
different infrastructure. There also may be differences in the quality
of the code, especially around how errors are handled.

If you want higher reliability,  I'd suggest wrapping nearly all
network API calls in a retry loop. If you get any sort of error: tcp,
http, parser, etc. retry with linear backoff.

-John Kalucki
http://twitter.com/jkalucki
Services, Twitter Inc.


On Sep 16, 10:23 am, Naveen A  wrote:
> Is there a specific way we can construct our request to mitigate the
> non-json response? I have used a few different twitter clients on the
> same mobile device and some of them do not seem to be plagued with the
> bad data like we are? Does including something in the header help get
> us through whatever filter is returning the bad data?
>
> Maybe the Twitter cookies that are returned back on each request?
> Currently, we don't pass them back on subsequent requests because they
> shouldn't be necessary, but if it will make some of the bad JSON
> responses go away, I'll spend the time to implement it..
>
> These bad json responses have been a problem for over a month now and
> while I realize it is a difficult problem to track down, the fact
> remains that the API is not functioning correctly.
>
> A response from the twitter team would be greatly appreciated.
>
> On Sep 13, 6:01 am, Rudifa  wrote:
>
> > I just had one non-json response, in the middle of about 10 requests
> > made with curl -vvv (other responses were correct)
>
> > Below are 3 requests and the non-json response bracketted by 2 good
> > responses which contain the response time and other logging data.
>
> > HTH
> > Rudi
>
> > rudolf-farkass-macbook-pro:TwitterWeb rudifarkas$ curl
-vvvhttp://twitter.com/users/show/rudifa.json
> > * About to connect() to twitter.com port 80 (#0)
> > *   Trying 168.143.161.20... connected
> > * Connected to twitter.com (168.143.161.20) port 80 (#0)> GET
/users/show/rudifa.json HTTP/1.1
> > > User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3
OpenSSL/0.9.7l zlib/1.2.3
> > > Host: twitter.com
> > > Accept: */*
>
> > < HTTP/1.1 200 OK
> > < Date: Sun, 13 Sep 2009 09:45:23 GMT
> > < Server: hi
> > < X-RateLimit-Limit: 150
> > < X-Transaction: 1252835123-2408-31139
> > < Status: 200 OK
> > < ETag: "df090f6c8147e20ba7fe81315a66b9af"
> > < Last-Modified: Sun, 13 Sep 2009 09:45:23 GMT
> > < X-RateLimit-Remaining: 124
> > < Content-Type: application/json; charset=utf-8
> > < Pragma: no-cache
> > < Content-Length: 1176
> > < Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,
> > post-check=0
> > < Expires: Tue, 31 Mar 1981 05:00:00 GMT
> > < X-Revision: a62881015b2c2fb6f795bf931bd56bd494f37254
> > < X-RateLimit-Reset: 1252836853
> > < Set-Cookie: lang=en; path=/
> > < Set-Cookie:
> >
_twitter_sess=BAh7CDoRdHJhbnNfcHJvbXB0MDoHaWQiJWU5OGQyZmU3NWVkY2RhZjhkYT
k5% 250ANTBlNTA4OTk0MzhhIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFz
> >
%250AaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA--66931156c75554797fc576876bdec52dc
705 736e;
> > domain=.twitter.com; path=/
> > < Vary: Accept-Encoding
> > < Connection: close
> > <
> > * Closing connection #0
> > {"profile_sidebar_border_color":"BDDCAD","description":"Wrote
firmware
> > for world-class osciloscopes for many years. Now learning iPhone
> > programming tricks. Loves
> > skiing.","url":null,"screen_name":"rudifa","status":
> >
{"in_reply_to_statu

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

[zippy_monster]

On Sep 16, 10:37 am, Alex Payne  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:



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] Batches of suspended users added back to social graphs

[RandyC]

I'm noticing from id lists pulled this morning that overnight there
appears to have been a large number of suspended ids added back to
various accounts.  Have I just not been watching closely or has anyone
else noticed this?

Randy

[twitter-dev] Detecting "denied" condition on Twitter oAuth page

[New guy]

Hi, while testing oAuth consumer code, I noticed that ..if the user
denies access to the app
(a) the post data includes "cancel=Deny"
and
(b) the response includes the string "OK, you've denied "
and if the user clicks on the app link, the user gets redirected to
the app URL with
(c) the app URL including the word "denied" in it.

I couldn't find any documentation stating that (a) and (c) are both
oficially supported behaviors for oAuth with Twitter.

I'm assuming that (a) and (c) are both corrects ways to determine
whether the app has been denied access, but can someone please point
me to documentation that confirms this.

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

[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  wrote:
>
> On Sep 16, 10:37 am, Alex Payne  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:
>
>  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

[zippy_monster]

On Sep 16, 1:41 pm, Alex Payne  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

[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  wrote:
>
> On Sep 16, 1:41 pm, Alex Payne  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: Detecting "denied" condition on Twitter oAuth page

[JDG]

If they deny, you shouldn't get an OAuth authorization token back. Can't you
just check for that?

Am I mistaken here? Do you always get a token back that just happens to be
invalid if they deny?

On Wed, Sep 16, 2009 at 14:08, New guy  wrote:

>
> Hi, while testing oAuth consumer code, I noticed that ..if the user
> denies access to the app
> (a) the post data includes "cancel=Deny"
> and
> (b) the response includes the string "OK, you've denied "
> and if the user clicks on the app link, the user gets redirected to
> the app URL with
> (c) the app URL including the word "denied" in it.
>
> I couldn't find any documentation stating that (a) and (c) are both
> oficially supported behaviors for oAuth with Twitter.
>
> I'm assuming that (a) and (c) are both corrects ways to determine
> whether the app has been denied access, but can someone please point
> me to documentation that confirms this.
>



-- 
Internets. Serious business.

[twitter-dev] SMS Notifications

[xzela]

Hi,

Does anyone know if it is possible to figure out how many users follow
you via SMS/Email notifications? I've searched the API documentation
(maybe not well enough) and was unable to find any information that
could lead to this development.

Is it impossible? Or am I not trying hard enough?

Any input would be welcomed.

[twitter-dev] Re: SMS Notifications

[Raffi Krikorian]

hi.

there is no API call that exposes how many of your followers (what  
subset of your followers) are following you by SMS.




Hi,

Does anyone know if it is possible to figure out how many users follow
you via SMS/Email notifications? I've searched the API documentation
(maybe not well enough) and was unable to find any information that
could lead to this development.

Is it impossible? Or am I not trying hard enough?

Any input would be welcomed.


--
Raffi Krikorian
Twitter Platform Team
ra...@twitter.com | @raffi

[twitter-dev] Re: Detecting "denied" condition on Twitter oAuth page

[New guy]

No, the oAuth login page doesn't provide oAuth access tokens
(regardless of whether the user approved or denied)

To get the oAuth access token, apps need to make a seperate oAuth GET
call (after the user has approved access on the oAuth login page)

On Sep 16, 2:36 pm, JDG  wrote:
> If they deny, you shouldn't get an OAuth authorization token back. Can't you
> just check for that?
>
> Am I mistaken here? Do you always get a token back that just happens to be
> invalid if they deny?
>
>
>
>
>
> On Wed, Sep 16, 2009 at 14:08, New guy  wrote:
>
> > Hi, while testing oAuth consumer code, I noticed that ..if the user
> > denies access to the app
> > (a) the post data includes "cancel=Deny"
> > and
> > (b) the response includes the string "OK, you've denied "
> > and if the user clicks on the app link, the user gets redirected to
> > the app URL with
> > (c) the app URL including the word "denied" in it.
>
> > I couldn't find any documentation stating that (a) and (c) are both
> > oficially supported behaviors for oAuth with Twitter.
>
> > I'm assuming that (a) and (c) are both corrects ways to determine
> > whether the app has been denied access, but can someone please point
> > me to documentation that confirms this.
>
> --
> Internets. Serious business.- Hide quoted text -
>
> - Show quoted text -

[twitter-dev] How to post data in twitter using oAuth system.

[Arifur Rahman]

Hello, i am struggling  to send data to twitter using oauth login.
Do any one help me.
Regard
ARIFUR RAHMAN

[twitter-dev] Re: Changes to Twitter TOS/Rules.

[Ryan Sarver]

Hardip,

Thanks for your email. Our intent is to stop spamming accounts. Your
use does not fall into that category, but its good practice to be
judicious when including a lot of links in your updates as it triggers
a lot of the filters that try to catch spam.

Best, Ryan

On Tue, Sep 15, 2009 at 7:58 AM, HardipSingh  wrote:
>
> I am curious how the following rule impact those that are auto-
> tweeting job links to #jobs and the other twitter job boards.
>
> * If your updates consist mainly of links, and not personal updates;
>
>
> Does this mean that we are in violation of this rule if I have an
> account that is primarily responsible for tweeting job links?
>
> Thanks in advance for your time.
>
> ~ H
>
>

[twitter-dev] Re: How to post data in twitter using oAuth system.

[Peter Denton]

Hi Arifur,
There are many oAuth examples, sorted by programming language.

http://apiwiki.twitter.com/OAuth-Examples

On Wed, Sep 16, 2009 at 3:40 PM, Arifur Rahman wrote:

>
> Hello, i am struggling  to send data to twitter using oauth login.
> Do any one help me.
> Regard
> ARIFUR RAHMAN
>

[twitter-dev] Re: How to post data in twitter using oAuth system.

[Arifur Rahman]

Peter Denton wrote:
But that do not help . I try but not able to post via asp.net
Regards
AIRFUR RAHMAN

Hi Arifur,
There are many oAuth examples, sorted by programming language.

http://apiwiki.twitter.com/OAuth-Examples

On Wed, Sep 16, 2009 at 3:40 PM, Arifur Rahman > wrote:



Hello, i am struggling  to send data to twitter using oauth login.
Do any one help me.
Regard
ARIFUR RAHMAN

[twitter-dev] Re: How to post data in twitter using oAuth system.

[John Meyer]

Arifur Rahman wrote:
>
> Peter Denton wrote:
> But that do not help . I try but not able to post via asp.net
> Regards

http://apiwiki.twitter.com/Libraries#C/NET


Or you can try the TwitterVB library.(http://code.google.com/p/twittervb)

[twitter-dev] Re: SMS Notifications

[xzela]

bummer,

well, thanks for the information though. I really appreciate it.

On Sep 16, 2:47 pm, Raffi Krikorian  wrote:
> hi.
>
> there is no API call that exposes how many of your followers (what  
> subset of your followers) are following you by SMS.
>
>
>
> > Hi,
>
> > Does anyone know if it is possible to figure out how many users follow
> > you via SMS/Email notifications? I've searched the API documentation
> > (maybe not well enough) and was unable to find any information that
> > could lead to this development.
>
> > Is it impossible? Or am I not trying hard enough?
>
> > Any input would be welcomed.
>
> --
> Raffi Krikorian
> Twitter Platform Team
> ra...@twitter.com | @raffi

[twitter-dev] Re: SMS Notifications

[Raffi Krikorian]

sorry!

what's your use case / what are you trying to accomplish?


bummer,

well, thanks for the information though. I really appreciate it.


hi.

there is no API call that exposes how many of your followers (what
subset of your followers) are following you by SMS.


Hi,


Does anyone know if it is possible to figure out how many users  
follow

you via SMS/Email notifications? I've searched the API documentation
(maybe not well enough) and was unable to find any information that
could lead to this development.



Is it impossible? Or am I not trying hard enough?



Any input would be welcomed.


--
Raffi Krikorian
Twitter Platform Team
ra...@twitter.com | @raffi

[twitter-dev] Re: SMS Notifications

[John Meyer]

xzela wrote:

bummer,

well, thanks for the information though. I really appreciate it.
  



Well, not directly, but you may be able to find out by how they post up 
their tweets if you go on the assumption that they use the same medium 
to post tweets as they do to receive them.

[twitter-dev] How would I get all messages from one user to another?

[Shpigford]

Specifically: All posts to @user_b from @user_a tagged 'example'

I initially tried this:
http://search.twitter.com/search.atom?q=&tag=example&lang=en&from=user_a&to=user_b

But since twitter apparently applies some arbitrary "quality" filter
on that, it somehow decides to not include some things. [http://
code.google.com/p/twitter-api/issues/detail?id=1042]

[twitter-dev] Posting non-English Characters using OAuth

[Mageuzi]

Hello,
I was hoping someone could help me, or point me in the right
direction.

I've written an app that used basic auth for a while, and of course
that worked great.  I'm now working on switching to OAuth, and
everything worked perfectly until I tried posting a status update that
used non-English characters, such as the following Japanese:

日本犬

In this case, I get a 401 Unauthorized error.  I've looked at the
signature and the encoding of the parameters, and it appears as if
everything is being processed correctly, but it's possible I missed
something.

I'm using C#, and the OAuth implementation I'm using can be found
here:
http://www.voiceoftech.com/swhitley/?p=681

The only changes made to that code involve adding support for the PIN
when first authorizing an account, but that isn't relevant to this.

Any help would be much appreciated, I'm not sure what to try at this
point.

[twitter-dev] My phone number is already in use

[angflowerchild]

I signed up for twitter months ago and did not want the information to
go to my phone at that time.  Know I do and I tried entering my number
but it states my number is already in use.  How can I change it?
Thank you, Ang

[twitter-dev] Re: My phone number is already in use

[Chad Etzel]

Hmm, I thought I moderated this message out of the queue... sorry for the noise.

In any event, please use http://help.twitter.com/ for general support issues.

-Chad

On Thu, Sep 17, 2009 at 1:42 AM, angflowerchild
 wrote:
>
> I signed up for twitter months ago and did not want the information to
> go to my phone at that time.  Know I do and I tried entering my number
> but it states my number is already in use.  How can I change it?
> Thank you, Ang
>