[twitter-dev] Re: counting rate limits against an oauth consumer

[Julio Biason]

Hey,

I'm guessing it would allow some abuse. Someone would start requesting
application IDs like crazy and spam the hell of the system. Once he
blow up one application ID, it would just switch to another one.

Although some sort of list-of-applications-sorted-by-requests would
allow a user to easily see the applications that are not behaving
nicely.

On Sun, Apr 12, 2009 at 1:16 PM, cpatil  wrote:
>
> Hi,
>
> Is there a reason why the rate limit is not applied to an oauth
> consumer (the application) instead of the authenticating user?
> It would prevent an offending application to use up the limits of a
> user and allow
> other applications continue to be able to service the user.
>
> thx/c
>



-- 
Julio Biason 
Twitter: http://twitter.com/juliobiason

[twitter-dev] counting rate limits against an oauth consumer

[cpatil]

Hi,

Is there a reason why the rate limit is not applied to an oauth
consumer (the application) instead of the authenticating user?
It would prevent an offending application to use up the limits of a
user and allow
other applications continue to be able to service the user.

thx/c

[twitter-dev] Using OAuth or API can u monitor Tweets & have 3rd party app react

[rpsfan]

Hi

Im wondering if our users whom have given us their Twitter name either
via OAuth or API would be able to Twitter a command or even a word and
when they do have it call to our app to take action?

If this can not be done then could we monitor our users Twitter
account every four hours to see if they have stated this action and if
so then we would take action?  Is there a limit to how many hits an
app can hit Twitter a day?

If the above was not clear here is an example 

Im Joe and Im on Twitter and this new thing a mo bob service.  Joe is
selling a couch in Murfreesboro, TN and Tweets Im selling a couch.
The word sell is what would trigger this thing a mo bob 3rd party app
and the app would search the web (craigslist and other sites) to find
buyers and send joe an email listing those buyers.

Thanks

Pardon if this is a double post my first after more then an hour has
note posted.  Please note this is for a legitimate web application and
the above example is just that.

[twitter-dev] Re: Double Basic Authentication When Post Follows Get

[Abraham Williams]

Well the API is what it is. I don't know of any open issues about supporting
sessions. I suppose you could open one.

On Sat, Apr 11, 2009 at 19:19, Adrian  wrote:

>
> It adds more complexity to my side. Sessions would be better atm.
>
> On Apr 12, 3:10 am, Cameron Kaiser  wrote:
> > > ..I can't and dont' want to access user credentials.
> >
> > > I'd love session support.
> >
> > Then you will love OAuth.
> >
> > --
> >  personal:
> http://www.cameronkaiser.com/--
> >   Cameron Kaiser * Floodgap Systems *www.floodgap.com*
> ckai...@floodgap.com
> > -- I'm a dyslexic amateur orthinologist. I just love word-botching.
> ---
>



-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: Out of sequence statuses

[Carlos Crosetti]

I am isterested in hearing - at this tme I ab sorting using the ID waht
to hear more... @ccrosetti

On Sat, Apr 11, 2009 at 8:42 PM, pcuenca - LateNiteSoft
wrote:

>
> Hello,
>
> We are in the process of developing a new native Mac twitter client,
> and I am having some difficulty in dealing with out-of-sequence
> statuses, i.e., statuses that should have appeared in a call to
> friends_timeline but make it to the stream later for some reason.
>
> So far I had successfully been using a combination of "since_id" and
> "since" requests to collect recent out-of-order posts that were
> missing in a previous request. I understand there were reasons to drop
> "since" requests and I'm sorry not to have voiced my concerns before;
> however, I'm not sure what's the best way to proceed with the current
> API in order to minimize the chance of missing posts. At the same
> time, I'm trying to minimize rate-limited API requests and honor
> recommended practices - being easy with the servers and all.
>
> As far as I understand it, out-of-order statuses are lost forever when
> using "since_id" to keep track of the last status returned by the
> server. Using since_id and then sweeping with unfiltered requests is
> expensive in terms of API rate limit and server performance. Using
> unfiltered requests only is not only uglier, but will also force the
> client to paginate back until a known status has been found, which
> results in an indeterminate number of API requests (especially for
> high-volume accounts, which we are determined to support).
>
> An idea that comes to mind is to use "since_id", but starting from a
> status a few minutes older than the most current one, instead of the
> latest. Does this approach sound feasible/reasonable? Is there any
> idea as to what's the typical time taken for a delayed message until
> it finally appears in the stream? I'm guessing going back a few
> minutes would recover 90% of lost posts, does this sound like a
> correct assumption?
>
> Also, are there any plans to deal with this scenario at the API level
> in the future? Maybe a parameter whereby results are returned by
> insertion timestamp, irrespective of the time they were created at or
> the ID they were assigned? Or maybe a "free" call (as in not counting
> against the limit) that mimics a standard timeline request but returns
> *just* the list of IDs?
>
> Thanks!
> @pcuenca - @latenitesoft
>
>


-- 
Carlos Crosetti

[twitter-dev] Re: StalkDaily worm - it's really spreading :)

[Alex Payne]

We've been on it for some time. It's actually not "really spreading",
and hasn't been for hours. Lots of people are talking about it, but
the actual attack vector is closed.

On Sat, Apr 11, 2009 at 19:05, Dossy Shiobara  wrote:
>
> I don't know if the Twitter folks are doing anything about it, but the
> StalkDaily worm is propagating fast.
>
> Better remove the user bio from Twitter profile pages and scrub the database
> ASAP ...
>
> --
> Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
> Panoptic Computer Network   | http://panoptic.com/
>  "He realized the fastest way to change is to laugh at your own
>    folly -- then you can let go and quickly move on." (p. 70)
>



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

[twitter-dev] StalkDaily worm - it's really spreading :)

[Dossy Shiobara]

I don't know if the Twitter folks are doing anything about it, but the 
StalkDaily worm is propagating fast.


Better remove the user bio from Twitter profile pages and scrub the 
database ASAP ...


--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  "He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[twitter-dev] Re: Freelance Twitter API Dev directory?

[Ammo Collector]

TwitterID: binhtran
Email: binhqtra...@gmail.com
Url: http://www.klout.net

[twitter-dev] Re: Double Basic Authentication When Post Follows Get

[Adrian]

It adds more complexity to my side. Sessions would be better atm.

On Apr 12, 3:10 am, Cameron Kaiser  wrote:
> > ..I can't and dont' want to access user credentials.
>
> > I'd love session support.
>
> Then you will love OAuth.
>
> --
>  personal:http://www.cameronkaiser.com/--
>   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com
> -- I'm a dyslexic amateur orthinologist. I just love word-botching. 
> ---

[twitter-dev] Re: Double Basic Authentication When Post Follows Get

[Cameron Kaiser]

> ..I can't and dont' want to access user credentials.
> 
> I'd love session support.

Then you will love OAuth.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- I'm a dyslexic amateur orthinologist. I just love word-botching. ---

[twitter-dev] Re: Double Basic Authentication When Post Follows Get

[Adrian]

do you mean just call:

username:passo...@https://twitter.com/statuses/update.xml

..I can't and dont' want to access user credentials.

I'd love session support.

On Apr 12, 3:04 am, Abraham Williams <4bra...@gmail.com> wrote:
> Sessions are not officially supported. You might as well just to include
> credentials with all calls.
>
>
>
> On Sat, Apr 11, 2009 at 18:57, Adrian  wrote:
>
> > Hi, on my client, if I run GET request, I'll have to authenticate but
> > after that all other GETs don't require authentication. Then, as soon
> > as there is a POST, I will have to re-authenticate. I'd prefer the
> > server just accepted the POST request as part of the session from the
> > already authenticated user and didn't reask for credentials. See
> > headers below: GET Request > Authenticate > POST Request > Fail
>
> >http://twitter.com/account/verify_credentials.json?callback=jsonp1239...
>
> > GET /account/verify_credentials.json?
> > callback=jsonp1239486621989&_=1239493435268 HTTP/1.1
> > Host: twitter.com
> > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
> > 1.9.0.8) Gecko/2009032609 Firefox/3.0.8
> > Accept: */*
> > Accept-Language: en-us,en;q=0.5
> > Accept-Encoding: gzip,deflate
> > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> > Keep-Alive: 300
> > Connection: keep-alive
> > Authorization: Basic ZGVzbWlkaXNvOmd3dHdnd3R3
>
> > HTTP/1.x 200 OK
> > Date: Sat, 11 Apr 2009 23:44:15 GMT
> > Server: hi
> > Last-Modified: Sat, 11 Apr 2009 23:44:15 GMT
> > Status: 200 OK
> > Etag: "a69811ab820044f3fcad85ed061bb512"-gzip
> > Pragma: no-cache
> > Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-
> > check=0
> > Content-Type: application/json; charset=utf-8
> > Expires: Tue, 31 Mar 1981 05:00:00 GMT
> > X-Revision: 0d279c956b77447dc8b68179a828f0d93a6e93e3
> > X-Transaction: 1239493455-52742-21090
> > Set-Cookie: lang=; path=/
> > Set-Cookie:
> > _twitter_sess=BAh7CToJdXNlcmkEKCLNAToTcGFzc3dvcmRfdG9rZW4iLWFkNmEzZGQzMzli
>
> > %250AOGRiZTE5YmViNTFlYzAwODZhYjRhZjE3NGY1OTE6B2lkIiU4MjAwYTFmYTA5%250AM2I4Z 
> > WUxYTEzNmJlOTQ4NmZlNzgzOCIKZmxhc2hJQzonQWN0aW9uQ29udHJv
> > %250AbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7AA%253D%253D--
> > b68d85bbacedd2a15c46152c514ac78fc30c1873; domain=.twitter.com; path=/
> > Vary: Accept-Encoding
> > Content-Encoding: gzip
> > Content-Length: 491
> > Connection: close
>
> > 
> >https://twitter.com/statuses/update.xml
>
> > POST /statuses/update.xml HTTP/1.1
> > Host: twitter.com
> > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
> > 1.9.0.8) Gecko/2009032609 Firefox/3.0.8
> > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/
> > *;q=0.8
> > Accept-Language: en-us,en;q=0.5
> > Accept-Encoding: gzip,deflate
> > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> > Keep-Alive: 300
> > Connection: keep-alive
> > Content-Type: application/x-www-form-urlencoded
> > Content-Length: 53
> > source=Twitya&in_reply_to_status_id=&status=Hello+God
> > HTTP/1.x 401 Unauthorized
> > Date: Sat, 11 Apr 2009 23:47:38 GMT
> > Server: hi
> > Status: 401 Unauthorized
> > WWW-Authenticate: Basic realm="Twitter API"
> > Cache-Control: no-cache, max-age=1800
> > Content-Type: application/xml; charset=utf-8
> > Set-Cookie:
> > _twitter_sess=BAh7BzoHaWQiJTc2OGQzNGEzNzlhNWYyNjliNTI1NDIzZTYxYmU4ZjkyIgpm
> > %250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG
> > %250AOgpAdXNlZHsA--546494cea99c2f48565af4f437ae265f04ed6bc6;
> > domain=.twitter.com; path=/
> > Expires: Sun, 12 Apr 2009 00:17:38 GMT
> > Vary: Accept-Encoding
> > Content-Encoding: gzip
> > Content-Length: 135
> > Connection: close
>
> --
> Abraham Williams |http://the.hackerconundrum.com
> Hacker |http://abrah.am|http://twitter.com/abraham
> Web608 | Community Evangelist |http://web608.org
> This email is: [ ] blogable [x] ask first [ ] private.
> Sent from Madison, Wisconsin, United States

[twitter-dev] Re: Double Basic Authentication When Post Follows Get

[Abraham Williams]

Sessions are not officially supported. You might as well just to include
credentials with all calls.

On Sat, Apr 11, 2009 at 18:57, Adrian  wrote:

>
> Hi, on my client, if I run GET request, I'll have to authenticate but
> after that all other GETs don't require authentication. Then, as soon
> as there is a POST, I will have to re-authenticate. I'd prefer the
> server just accepted the POST request as part of the session from the
> already authenticated user and didn't reask for credentials. See
> headers below: GET Request > Authenticate > POST Request > Fail
>
>
>
>
> http://twitter.com/account/verify_credentials.json?callback=jsonp1239486621989&_=1239493435268
>
> GET /account/verify_credentials.json?
> callback=jsonp1239486621989&_=1239493435268 HTTP/1.1
> Host: twitter.com
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
> 1.9.0.8) Gecko/2009032609 Firefox/3.0.8
> Accept: */*
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Authorization: Basic ZGVzbWlkaXNvOmd3dHdnd3R3
>
> HTTP/1.x 200 OK
> Date: Sat, 11 Apr 2009 23:44:15 GMT
> Server: hi
> Last-Modified: Sat, 11 Apr 2009 23:44:15 GMT
> Status: 200 OK
> Etag: "a69811ab820044f3fcad85ed061bb512"-gzip
> Pragma: no-cache
> Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-
> check=0
> Content-Type: application/json; charset=utf-8
> Expires: Tue, 31 Mar 1981 05:00:00 GMT
> X-Revision: 0d279c956b77447dc8b68179a828f0d93a6e93e3
> X-Transaction: 1239493455-52742-21090
> Set-Cookie: lang=; path=/
> Set-Cookie:
> _twitter_sess=BAh7CToJdXNlcmkEKCLNAToTcGFzc3dvcmRfdG9rZW4iLWFkNmEzZGQzMzli
>
> %250AOGRiZTE5YmViNTFlYzAwODZhYjRhZjE3NGY1OTE6B2lkIiU4MjAwYTFmYTA5%250AM2I4ZWUxYTEzNmJlOTQ4NmZlNzgzOCIKZmxhc2hJQzonQWN0aW9uQ29udHJv
> %250AbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7AA%253D%253D--
> b68d85bbacedd2a15c46152c514ac78fc30c1873; domain=.twitter.com; path=/
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 491
> Connection: close
>
> 
> https://twitter.com/statuses/update.xml
>
> POST /statuses/update.xml HTTP/1.1
> Host: twitter.com
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
> 1.9.0.8) Gecko/2009032609 Firefox/3.0.8
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/
> *;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 53
> source=Twitya&in_reply_to_status_id=&status=Hello+God
> HTTP/1.x 401 Unauthorized
> Date: Sat, 11 Apr 2009 23:47:38 GMT
> Server: hi
> Status: 401 Unauthorized
> WWW-Authenticate: Basic realm="Twitter API"
> Cache-Control: no-cache, max-age=1800
> Content-Type: application/xml; charset=utf-8
> Set-Cookie:
> _twitter_sess=BAh7BzoHaWQiJTc2OGQzNGEzNzlhNWYyNjliNTI1NDIzZTYxYmU4ZjkyIgpm
> %250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG
> %250AOgpAdXNlZHsA--546494cea99c2f48565af4f437ae265f04ed6bc6;
> domain=.twitter.com; path=/
> Expires: Sun, 12 Apr 2009 00:17:38 GMT
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 135
> Connection: close
>
>


-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Double Basic Authentication When Post Follows Get

[Adrian]

Hi, on my client, if I run GET request, I'll have to authenticate but
after that all other GETs don't require authentication. Then, as soon
as there is a POST, I will have to re-authenticate. I'd prefer the
server just accepted the POST request as part of the session from the
already authenticated user and didn't reask for credentials. See
headers below: GET Request > Authenticate > POST Request > Fail



http://twitter.com/account/verify_credentials.json?callback=jsonp1239486621989&_=1239493435268

GET /account/verify_credentials.json?
callback=jsonp1239486621989&_=1239493435268 HTTP/1.1
Host: twitter.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Authorization: Basic ZGVzbWlkaXNvOmd3dHdnd3R3

HTTP/1.x 200 OK
Date: Sat, 11 Apr 2009 23:44:15 GMT
Server: hi
Last-Modified: Sat, 11 Apr 2009 23:44:15 GMT
Status: 200 OK
Etag: "a69811ab820044f3fcad85ed061bb512"-gzip
Pragma: no-cache
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-
check=0
Content-Type: application/json; charset=utf-8
Expires: Tue, 31 Mar 1981 05:00:00 GMT
X-Revision: 0d279c956b77447dc8b68179a828f0d93a6e93e3
X-Transaction: 1239493455-52742-21090
Set-Cookie: lang=; path=/
Set-Cookie:
_twitter_sess=BAh7CToJdXNlcmkEKCLNAToTcGFzc3dvcmRfdG9rZW4iLWFkNmEzZGQzMzli
%250AOGRiZTE5YmViNTFlYzAwODZhYjRhZjE3NGY1OTE6B2lkIiU4MjAwYTFmYTA5%250AM2I4ZWUxYTEzNmJlOTQ4NmZlNzgzOCIKZmxhc2hJQzonQWN0aW9uQ29udHJv
%250AbGxlcjo6Rmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7AA%253D%253D--
b68d85bbacedd2a15c46152c514ac78fc30c1873; domain=.twitter.com; path=/
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 491
Connection: close


https://twitter.com/statuses/update.xml

POST /statuses/update.xml HTTP/1.1
Host: twitter.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/
*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 53
source=Twitya&in_reply_to_status_id=&status=Hello+God
HTTP/1.x 401 Unauthorized
Date: Sat, 11 Apr 2009 23:47:38 GMT
Server: hi
Status: 401 Unauthorized
WWW-Authenticate: Basic realm="Twitter API"
Cache-Control: no-cache, max-age=1800
Content-Type: application/xml; charset=utf-8
Set-Cookie:
_twitter_sess=BAh7BzoHaWQiJTc2OGQzNGEzNzlhNWYyNjliNTI1NDIzZTYxYmU4ZjkyIgpm
%250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG
%250AOgpAdXNlZHsA--546494cea99c2f48565af4f437ae265f04ed6bc6;
domain=.twitter.com; path=/
Expires: Sun, 12 Apr 2009 00:17:38 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 135
Connection: close

[twitter-dev] Re: Out of sequence statuses

[Cameron Kaiser]

> We are in the process of developing a new native Mac twitter client,
> and I am having some difficulty in dealing with out-of-sequence
> statuses, i.e., statuses that should have appeared in a call to
> friends_timeline but make it to the stream later for some reason.

I would imagine the aim is to make the timeline fast enough that this
doesn't happen (much if ever).

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- require "std_disclaimer.pl"; ---

[twitter-dev] Out of sequence statuses

[pcuenca - LateNiteSoft]

Hello,

We are in the process of developing a new native Mac twitter client,
and I am having some difficulty in dealing with out-of-sequence
statuses, i.e., statuses that should have appeared in a call to
friends_timeline but make it to the stream later for some reason.

So far I had successfully been using a combination of "since_id" and
"since" requests to collect recent out-of-order posts that were
missing in a previous request. I understand there were reasons to drop
"since" requests and I'm sorry not to have voiced my concerns before;
however, I'm not sure what's the best way to proceed with the current
API in order to minimize the chance of missing posts. At the same
time, I'm trying to minimize rate-limited API requests and honor
recommended practices - being easy with the servers and all.

As far as I understand it, out-of-order statuses are lost forever when
using "since_id" to keep track of the last status returned by the
server. Using since_id and then sweeping with unfiltered requests is
expensive in terms of API rate limit and server performance. Using
unfiltered requests only is not only uglier, but will also force the
client to paginate back until a known status has been found, which
results in an indeterminate number of API requests (especially for
high-volume accounts, which we are determined to support).

An idea that comes to mind is to use "since_id", but starting from a
status a few minutes older than the most current one, instead of the
latest. Does this approach sound feasible/reasonable? Is there any
idea as to what's the typical time taken for a delayed message until
it finally appears in the stream? I'm guessing going back a few
minutes would recover 90% of lost posts, does this sound like a
correct assumption?

Also, are there any plans to deal with this scenario at the API level
in the future? Maybe a parameter whereby results are returned by
insertion timestamp, irrespective of the time they were created at or
the ID they were assigned? Or maybe a "free" call (as in not counting
against the limit) that mimics a standard timeline request but returns
*just* the list of IDs?

Thanks!
@pcuenca - @latenitesoft

[twitter-dev] Re: Settings->Connections

[Mobasoft]

Verified. Works for me. Thanks!

On Apr 10, 6:44 pm, Matt Sanford  wrote:
> Hi there,
>
>      A fix for this was deployed a few moments ago.
>
> Thanks;
>    — Matt Sanford
>
> On Apr 10, 2009, at 05:19 AM, Mobasoft wrote:
>
>
>
> > Friday morning report: still seeing 500 error on the connections tab
> > in some accounts.
>
> > On Apr 8, 11:40 am, Doug Williams  wrote:
> >> There were a lot of system issues that could have caused the  
> >> robots. The
> >> site should be much happier as the week goes on. Thanks for your  
> >> patience.
>
> >> Doug Williams
> >> Twitter API Supporthttp://twitter.com/dougw
>
> >> On Wed, Apr 8, 2009 at 4:28 AM, Mobasoft  wrote:
>
> >>> Checked again this morning - after seeing robots on the home page  
> >>> and
> >>> now link to logout (UI flaw) I cleared browser cookies and tried
> >>> again. Now I see the connections tab and the one authenticated
> >>> application for that account.
>
> >>> On Apr 7, 5:11 pm, Mobasoft  wrote:
>  I have another account, where I could not see the Connections  
>  tab, but
>  was able to navigate to the url.
>  I've also just granted OAuth access to that account and I still  
>  do not
>  see a Connections tab, and navigating to the connections url still
>  says, "No applications have been approved to use your account."
>
>  I'll assume that it is a Twitter caching problem (which seems to  
>  have
>  been a bigger overall problem lately).
>
>  If it shows up anytime soon, I'll add another reply here.
>
>  Michael
>
>  On Apr 7, 4:56 pm, Mobasoft  wrote:
>
> > Robots.
> > "Something is technically wrong.
> > Thanks for noticing—we're going to fix it up and have things  
> > back to
> > normal soon."
>
> > On Apr 7, 4:53 pm, Doug Williams  wrote:
>
> >> Michael,
> >> All of the API development team read this forum so it's the best
> >>> place for
> >> issues like this. As Chad replied, the connections tab is  
> >> working for
> >>> me as
> >> expected. Can you go into more detail about what you are seeing  
> >> that
> >>> seems
> >> off?
>
> >> Doug Williams
> >> Twitter API Supporthttp://twitter.com/dougw
>
> >> On Tue, Apr 7, 2009 at 2:43 PM, Chad Etzel 
> >>> wrote:
>
> >>> Working for me, and displaying all of the authorized apps I've
> >>> used...
> >>> -Chad
>
> >>> On Tue, Apr 7, 2009 at 5:41 PM, Mobasoft 
> >>> wrote:
>
>  I understand that a lot of this OAuth development has been and
> >>> out of
>  some flux lately, but is thathttps://
> >>> twitter.com/account/connections
>  link working for anyone?
>
>  If there is a more prominent place to ask Twitter dev team
> >>> directly,
>  please inform me.
>
>  Thanks,
>
>  Michael

[twitter-dev] Re: Oauth application directory

[Petermdenton]

Actually if everyone is open to it , I was working on a site to  
showcase developers and apps, more for devs than consumers. Would  
anyone want such a thing?



On Apr 11, 2009, at 1:22 PM, Abraham Williams <4bra...@gmail.com> wrote:


You can always start an unofficial one on http://twitter.pbwiki.com

On Sat, Apr 11, 2009 at 13:56, Alex Payne  wrote:

Not yet, but soon!

On Sat, Apr 11, 2009 at 07:17, Alberto Bajo   
wrote:

>
> Hi guys,
>
> Is there any list or directory with applications implementing OAuth?
>
> Thanks :)
>
> --
> Alberto Bajo
> alber...@ideateca.com
> http://filesocial.com
>



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



--
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: Oauth application directory

[Abraham Williams]

You can always start an unofficial one on http://twitter.pbwiki.com

On Sat, Apr 11, 2009 at 13:56, Alex Payne  wrote:

>
> Not yet, but soon!
>
> On Sat, Apr 11, 2009 at 07:17, Alberto Bajo  wrote:
> >
> > Hi guys,
> >
> > Is there any list or directory with applications implementing OAuth?
> >
> > Thanks :)
> >
> > --
> > Alberto Bajo
> > alber...@ideateca.com
> > http://filesocial.com
> >
>
>
>
> --
> Alex Payne - API Lead, Twitter, Inc.
> http://twitter.com/al3x
>



-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: Can search API return just Number of query matches?

[Abraham Williams]

No. Counting the responses you get is currently the only way.

Abraham

On Sat, Apr 11, 2009 at 14:07, Michelle Guy  wrote:

> Is it possible to get back just the total number of tweets (non the actualy
> tweets themselves) that match a query submitted via the Search API?  For
> example, can i get back the total number of tweets that have a particular
> phrase?  I am not looking to get the tweets text, nor any other tweet
> information, only the total count of tweets that match my query criteria.
>
> I know I can specify the number of returns per page, and then request each
> additional page until there are no more (up to the 1500 limit per query),
> but I'm hoping to reduce the number of queries and hits I need to make to
> twitter.com.
>
> thanks,
> michelle
>



-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: [twitter-api-announce] A note on our API change policy

[Abraham Williams]

If versioning is used how long should versions be supported? A week? A
month? Lets just say a month for now. If Twitter pushes out changes every 2
days it is possible that there would be 15 versions running at any given
time. This is an extreme example but something to think about.

On Sat, Apr 11, 2009 at 13:56, Alex Payne  wrote:

>
> Right now, every new machine we get goes immediately into production.
> Once we have enough machines that we can get ahead of that capacity
> planning, I think a "beta.api.twitter.com" is a great idea. And/or
> versioning.
>
> On Sat, Apr 11, 2009 at 11:00, Yu-Shan Fung  wrote:
> > I second Jesse's suggestion. Having a staging server to test out API
> changes
> > would help smooth out transitions (though people needs to be careful
> about
> > what change they make as presumably this will run against prod database).
> > That way your internal developers can directly push code ready for
> release
> > immediately to staging instead of waiting 5 days.
> > It'll probably also help sanity internally at Twitter. Who knows, with
> > developers hitting the staging API before it goes out, we might even help
> > catch a bug or two once in a while before it goes out :-)
> > Yu-Shan
> >
> > On Sat, Apr 11, 2009 at 2:21 AM, Jesse Stay  wrote:
> >>
> >> Doug, can you guys do what Facebook is doing, and release it on a beta
> >> server somewhere beforehand so we can test it on our apps before you
> >> actually release it to the public?  A public staging server of some
> sort.
> >>  That will keep these surprises from happening, and we can start working
> out
> >> alerts to have in place when things might break our code that go on that
> >> beta server.  Best of all, it won't ever affect the end user.  Keep the
> >> releases on that server, then the releases out to the public on a timed
> >> release schedule.  It might take a little longer to get out to the
> public,
> >> but you'll have a much happier developer base and in turn a much happier
> end
> >> user by doing so.  That would be my number one suggestion.
> >>
> >>
> >>
> >> Do you guys do any tracking of Twitter itself for developers complaining
> >> about the API? I would also think you could gain some insight from that
> as
> >> well.
> >> @Jesse
> >>
> >>
> >> On Fri, Apr 10, 2009 at 12:04 PM, Doug Williams 
> wrote:
> >>>
> >>> Twitter's development model is pragmatically agile where features enter
> >>> the code base right alongside bug fixes. You can see this in our
> changelog
> >>> [1]. What is not clear from the log is that most of the code is written
> just
> >>> days before.
> >>>
> >>> April 8th's rapid deprecation of the since parameter/If-Modified-Since
> >>> header (and to a lesser extent, the removal of undocumented HTTP POST
> access
> >>> to accounts/verify_credentials) [5] caught a number of developers off
> guard.
> >>> The criticism of this hasty change on the impact to hackers and
> businesses
> >>> alike was both valid and appropriate. The results from last month's
> survey
> >>> [6] lead us to believe that the use of this parameter was minimal and
> that
> >>> it was safe to capture performance gains through the deprecation. In
> >>> hindsight, our sample size was statistically insignificant because we
> made a
> >>> mistake.
> >>>
> >>> It is apparent we need to make a change towards transparency. Openness
> >>> demands we give developers a clear line of communication when changes
> are
> >>> made that will break current functionality. While these changes are
> rare,
> >>> they do happen. As a result of this week's conversation, we will give a
> >>> minimum of 5 business days notice before we ship code that removes
> currently
> >>> documented functionality. Two notable exceptions are critical security
> and
> >>> performance fixes.
> >>>
> >>> Five days may seem short notice but it is a compromise from our
> standard.
> >>> There are two major concerns we must consider when shelving code that
> is
> >>> ready for deploy:
> >>> 1) We do not write unnecessary code. Code only exists in the deploy
> >>> pipeline for a feature or defect fix that is ready to go out the door.
> We
> >>> view deployable code as an asset that should be handling requests as
> quickly
> >>> as possible.
> >>> 2) Un-merged code adds complexity. The Twitter code base is constantly
> >>> moving. Deploying code requires merging with the master branch which
> grows
> >>> in complexity as an undeployed branch sits idle.
> >>>
> >>> We currently use the changelog [1], @twitterapi [2], The API Announce
> >>> List [3], and the Dev Group [4] to inform developers of changes in
> hopes
> >>> that features will get used, and deprecations will be honored. I'd
> suggest
> >>> any developer with a long-running application to subscribe to the low
> noise,
> >>> only signal, API Announce mailing-list [3] to receive API updates as
> they
> >>> are released.
> >>>
> >>> Lastly, lets work together. Tell me what you developers need that we
> are
> >>> not 

[twitter-dev] Can search API return just Number of query matches?

[Michelle Guy]

Is it possible to get back just the total number of tweets (non the actualy
tweets themselves) that match a query submitted via the Search API?  For
example, can i get back the total number of tweets that have a particular
phrase?  I am not looking to get the tweets text, nor any other tweet
information, only the total count of tweets that match my query criteria.

I know I can specify the number of returns per page, and then request each
additional page until there are no more (up to the 1500 limit per query),
but I'm hoping to reduce the number of queries and hits I need to make to
twitter.com.

thanks,
michelle

[twitter-dev] Re: Article about my experiences deploying a Twitter Web app on Google App Engine Java

[Abraham Williams]

Heh. Just as I sent that i remember that you are working with Scala :-/
My bad.

On Sat, Apr 11, 2009 at 15:10, Abraham Williams <4bra...@gmail.com> wrote:

> There is a Python OAuth lib [1] that @harper wrote and is using on App
> Engine. That would be a sweet addition.
>
> [1]  http://github.com/harperreed/twitteroauth-python/tree/master
>
>
> On Sat, Apr 11, 2009 at 13:58, Alex Payne  wrote:
>
>>
>> Handy!
>>
>> On Sat, Apr 11, 2009 at 09:30, Dave Briccetti 
>> wrote:
>> >
>> > Perhaps this will save time for some of you.
>> >
>> >
>> http://briccetti.blogspot.com/2009/04/my-first-scala-web-app-on-google-app.html
>> >
>> >
>>
>>
>>
>> --
>> Alex Payne - API Lead, Twitter, Inc.
>> http://twitter.com/al3x
>>
>
>
>
> --
> Abraham Williams | http://the.hackerconundrum.com
> Hacker | http://abrah.am | http://twitter.com/abraham
> Web608 | Community Evangelist | http://web608.org
> This email is: [ ] blogable [x] ask first [ ] private.
> Sent from Madison, Wisconsin, United States




-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: Article about my experiences deploying a Twitter Web app on Google App Engine Java

[Abraham Williams]

There is a Python OAuth lib [1] that @harper wrote and is using on App
Engine. That would be a sweet addition.

[1]  http://github.com/harperreed/twitteroauth-python/tree/master

On Sat, Apr 11, 2009 at 13:58, Alex Payne  wrote:

>
> Handy!
>
> On Sat, Apr 11, 2009 at 09:30, Dave Briccetti  wrote:
> >
> > Perhaps this will save time for some of you.
> >
> >
> http://briccetti.blogspot.com/2009/04/my-first-scala-web-app-on-google-app.html
> >
> >
>
>
>
> --
> Alex Payne - API Lead, Twitter, Inc.
> http://twitter.com/al3x
>



-- 
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[twitter-dev] Re: I get new follower mails, but I'm not followed

[Terry Jones]

Here's another one, just in this minute.

Terry

> From: Twitter 
> Subject: Molly Gould is now following you on Twitter!
> Date: Sat, 11 Apr 2009 19:59:49 +
> To: terry
> 
> Hi, Terry Jones (terrycojones).
> 
> Molly Gould (mollygould) is now following your updates on Twitter.
> 
> Check out Molly Gould's profile here:
>   http://twitter.com/mollygould
> 
> You may follow Molly Gould as well by clicking on the "follow" button.
> Best,
> Twitter

[twitter-dev] Re: I get new follower mails, but I'm not followed

[Terry Jones]

Hi Alex

> This is the first I've heard of it, but I'll double-check with our spam
> team.

If you've not heard anything, it's likely just coincidence. In any case,
here are some of my apparently phantom follows from the last couple of
days:

  JTNVEGAS, Raine93, BartGA, ronquart, shrryfllr

People don't usually unfollow so rapidly. I don't know how much of a delay
Twitter has in outgoing SMTP, but some of the above I have checked
immediately on receiving the follow notification in mail, and I've not been
on their following list.

Terry

[twitter-dev] Re: "Failed to validate oauth signature or token" on status update post?

[Dominik Schwind]

On Sat, Apr 11, 2009 at 6:40 PM, jmathai  wrote:
>
> Here's a bug for the problem: 
> http://code.google.com/p/twitter-api/issues/detail?id=447

K, thx, I answered the questions there, I hope it helps. :)

[twitter-dev] Re: I get new follower mails, but I'm not followed

[Alex Payne]

This is the first I've heard of it, but I'll double-check with our spam team.

On Sat, Apr 11, 2009 at 08:50, Terry Jones  wrote:
>
> Hi all
>
> I've been getting a lot of mails telling me people are following me, but
> when I click to take a look at the person I am not being followed by them.
>
> At first I just assumed this was some kind of eventual consistency issue
> with Twitter and that the web interface was showing the person with a
> slightly out of date follower list.  When I check with the API I also don't
> see the person as following me.
>
> I've seen this (I guess) 20 times in the last few days.
>
> I'm wondering what's going on. Is it just spammers (or others) creating
> accounts, following many people, then immediately unfollowing? I also read
> about the StalkDaily worm, so (if the worm exists and works as described) I
> suppose if you wanted to infect people you could create new accounts and
> then just follow/unfollow people. See
> http://kodespark.tumblr.com/post/95149076/the-stalkdaily-worm-on-twitter
>
> Often twitter.com with show the person who's apparently following (but
> isn't or no longer is) as following a high numeric number, but the number
> of little icons of people they're following will be much much smaller.
> That, I think, is just Twitter not having caught up with itself.
>
> Anyway, I'm just commenting out loud, and wondering whether others are
> seeing this. I imagine it must be widespread.
>
> Terry
>



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

[twitter-dev] Re: Messages with accented characters get truncated

[Alex Payne]

New one to me. Please file: http://code.google.com/p/twitter-api/issues/entry

On Sat, Apr 11, 2009 at 00:15, John  wrote:
>
> I use a Windows function called InternetCanonicalizeUrl to encode
> status messages before posting them to Twitter. It encodes é as %E9.
> So for example, "café mocha" turns to "caf%E9%20mocha".
>
> When I post this as a status update to Twitter, it shows up as
> "caféocha". The "m" is dropped for some reason. Is this a known issue?
>
> Thanks.
>



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

[twitter-dev] Re: Article about my experiences deploying a Twitter Web app on Google App Engine Java

[Alex Payne]

Handy!

On Sat, Apr 11, 2009 at 09:30, Dave Briccetti  wrote:
>
> Perhaps this will save time for some of you.
>
> http://briccetti.blogspot.com/2009/04/my-first-scala-web-app-on-google-app.html
>
>



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

[twitter-dev] Re: Oauth application directory

[Alex Payne]

Not yet, but soon!

On Sat, Apr 11, 2009 at 07:17, Alberto Bajo  wrote:
>
> Hi guys,
>
> Is there any list or directory with applications implementing OAuth?
>
> Thanks :)
>
> --
> Alberto Bajo
> alber...@ideateca.com
> http://filesocial.com
>



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

[twitter-dev] Re: [twitter-api-announce] A note on our API change policy

[Alex Payne]

Right now, every new machine we get goes immediately into production.
Once we have enough machines that we can get ahead of that capacity
planning, I think a "beta.api.twitter.com" is a great idea. And/or
versioning.

On Sat, Apr 11, 2009 at 11:00, Yu-Shan Fung  wrote:
> I second Jesse's suggestion. Having a staging server to test out API changes
> would help smooth out transitions (though people needs to be careful about
> what change they make as presumably this will run against prod database).
> That way your internal developers can directly push code ready for release
> immediately to staging instead of waiting 5 days.
> It'll probably also help sanity internally at Twitter. Who knows, with
> developers hitting the staging API before it goes out, we might even help
> catch a bug or two once in a while before it goes out :-)
> Yu-Shan
>
> On Sat, Apr 11, 2009 at 2:21 AM, Jesse Stay  wrote:
>>
>> Doug, can you guys do what Facebook is doing, and release it on a beta
>> server somewhere beforehand so we can test it on our apps before you
>> actually release it to the public?  A public staging server of some sort.
>>  That will keep these surprises from happening, and we can start working out
>> alerts to have in place when things might break our code that go on that
>> beta server.  Best of all, it won't ever affect the end user.  Keep the
>> releases on that server, then the releases out to the public on a timed
>> release schedule.  It might take a little longer to get out to the public,
>> but you'll have a much happier developer base and in turn a much happier end
>> user by doing so.  That would be my number one suggestion.
>>
>>
>>
>> Do you guys do any tracking of Twitter itself for developers complaining
>> about the API? I would also think you could gain some insight from that as
>> well.
>> @Jesse
>>
>>
>> On Fri, Apr 10, 2009 at 12:04 PM, Doug Williams  wrote:
>>>
>>> Twitter's development model is pragmatically agile where features enter
>>> the code base right alongside bug fixes. You can see this in our changelog
>>> [1]. What is not clear from the log is that most of the code is written just
>>> days before.
>>>
>>> April 8th's rapid deprecation of the since parameter/If-Modified-Since
>>> header (and to a lesser extent, the removal of undocumented HTTP POST access
>>> to accounts/verify_credentials) [5] caught a number of developers off guard.
>>> The criticism of this hasty change on the impact to hackers and businesses
>>> alike was both valid and appropriate. The results from last month's survey
>>> [6] lead us to believe that the use of this parameter was minimal and that
>>> it was safe to capture performance gains through the deprecation. In
>>> hindsight, our sample size was statistically insignificant because we made a
>>> mistake.
>>>
>>> It is apparent we need to make a change towards transparency. Openness
>>> demands we give developers a clear line of communication when changes are
>>> made that will break current functionality. While these changes are rare,
>>> they do happen. As a result of this week's conversation, we will give a
>>> minimum of 5 business days notice before we ship code that removes currently
>>> documented functionality. Two notable exceptions are critical security and
>>> performance fixes.
>>>
>>> Five days may seem short notice but it is a compromise from our standard.
>>> There are two major concerns we must consider when shelving code that is
>>> ready for deploy:
>>> 1) We do not write unnecessary code. Code only exists in the deploy
>>> pipeline for a feature or defect fix that is ready to go out the door. We
>>> view deployable code as an asset that should be handling requests as quickly
>>> as possible.
>>> 2) Un-merged code adds complexity. The Twitter code base is constantly
>>> moving. Deploying code requires merging with the master branch which grows
>>> in complexity as an undeployed branch sits idle.
>>>
>>> We currently use the changelog [1], @twitterapi [2], The API Announce
>>> List [3], and the Dev Group [4] to inform developers of changes in hopes
>>> that features will get used, and deprecations will be honored. I'd suggest
>>> any developer with a long-running application to subscribe to the low noise,
>>> only signal, API Announce mailing-list [3] to receive API updates as they
>>> are released.
>>>
>>> Lastly, lets work together. Tell me what you developers need that we are
>>> not currently providing. How can we better manage this communication? Which
>>> method of notifications work best for you? Aside from transparency with API
>>> changes, what else do you want to know?
>>>
>>> 1. http://apiwiki.twitter.com/REST+API+Changelog
>>> 2. http://twitter.com/twitterapi
>>> 3. http://groups.google.com/group/twitter-api-announce?hl=en
>>> 4. http://groups.google.com/group/twitter-development-talk
>>> 5.
>>> http://groups.google.com/group/twitter-api-announce/browse_frm/thread/5822fbfd5ea857c6?hl=en
>>> 6.
>>> http://groups.google.com/gro

[twitter-dev] Re: "Failed to validate oauth signature or token" on status update post?

[jmathai]

Here's a bug for the problem: 
http://code.google.com/p/twitter-api/issues/detail?id=447

On Apr 11, 8:20 am, Dominik Schwind  wrote:
> Hm, I'm always calling write stuff, like /status/update, with POST -
> actually I thought it's not possible to GET those calls. Still not
> working on my end, even if I try around with those headers.
>
>
>
> On Sat, Apr 11, 2009 at 2:44 PM, Bluespark  wrote:
>
> > I have got my Python library working.  It simply is just changing the
> > GET to post. When you encode your token and other items, you have to
> > make sure you change this to a POST for the /status/update method.
>
> > Calling status/update with a GET got me the 401 Authorization failed.
>
> > This was a pretty easy fix, once you know where to look in your
> > library.
>
> > On Apr 11, 5:07 pm, jmathai  wrote:
> >> I am having this problem as well.  GETs work fine but POSTs do not.  I
> >> don't have any Authorization headers.
>
> >> On Apr 10, 10:37 am, Chen Jie  wrote:
>
> >> > I got a workaround for POST, I removed Authorization info in Header,
> >> > then the POST request passed.
>
> >> > On Apr 10, 8:50 pm, max  wrote:
>
> >> > > I have the same problem since this morning, pretty strange, looked
> >> > > over my code but I really don't see anything wrong.
>
> >> > > On Apr 10, 4:27 am, HSL  wrote:
>
> >> > > > Anyone else has the problem that posting a status update through 
> >> > > > OAuth
> >> > > > gives the error: "failed to validate oauth signatre or token" since a
> >> > > > few hours?
>
> --
> Dominik Schwindwww.lostfocus.de
>
> Other ways to contact me onwww.dominikschwind.com

[twitter-dev] Destroy twitter ?

[heinzrainer]

Destroy twitter is today's best platform to post / read / organize
twitter blogging.
I have used several platforms and found the Adobe Air based to be one
of the best.

http://www.squidoo.com/aheneghana
http://www.squidoo.com/moringa

[twitter-dev] Re: [twitter-api-announce] A note on our API change policy

[Yu-Shan Fung]

I second Jesse's suggestion. Having a staging server to test out API changes
would help smooth out transitions (though people needs to be careful about
what change they make as presumably this will run against prod database).
That way your internal developers can directly push code ready for release
immediately to staging instead of waiting 5 days.
It'll probably also help sanity internally at Twitter. Who knows, with
developers hitting the staging API before it goes out, we might even help
catch a bug or two once in a while before it goes out :-)

Yu-Shan


On Sat, Apr 11, 2009 at 2:21 AM, Jesse Stay  wrote:

> Doug, can you guys do what Facebook is doing, and release it on a beta server 
> somewhere beforehand so we can test it on our apps before you actually 
> release it to the public?  A public staging server of some sort.  That will 
> keep these surprises from happening, and we can start working out alerts to 
> have in place when things might break our code that go on that beta server.  
> Best of all, it won't ever affect the end user.  Keep the releases on that 
> server, then the releases out to the public on a timed release schedule.  It 
> might take a little longer to get out to the public, but you'll have a much 
> happier developer base and in turn a much happier end user by doing so.  That 
> would be my number one suggestion.
>
> Do you guys do any tracking of Twitter itself for developers complaining 
> about the API? I would also think you could gain some insight from that as 
> well.
>
> @Jesse
>
> On Fri, Apr 10, 2009 at 12:04 PM, Doug Williams  wrote:
>
>> Twitter's development model is pragmatically agile where features enter
>> the code base right alongside bug fixes. You can see this in our changelog
>> [1]. What is not clear from the log is that most of the code is written just
>> days before.
>>
>> April 8th's rapid deprecation of the since parameter/If-Modified-Since
>> header (and to a lesser extent, the removal of undocumented HTTP POST access
>> to accounts/verify_credentials) [5] caught a number of developers off guard.
>> The criticism of this hasty change on the impact to hackers and businesses
>> alike was both valid and appropriate. The results from last month's survey
>> [6] lead us to believe that the use of this parameter was minimal and that
>> it was safe to capture performance gains through the deprecation. In
>> hindsight, our sample size was statistically insignificant because we made a
>> mistake.
>>
>> It is apparent we need to make a change towards transparency. Openness
>> demands we give developers a clear line of communication when changes are
>> made that will break current functionality. While these changes are rare,
>> they do happen. As a result of this week's conversation, we will give a
>> minimum of 5 business days notice before we ship code that removes currently
>> documented functionality. Two notable exceptions are critical security and
>> performance fixes.
>>
>> Five days may seem short notice but it is a compromise from our standard.
>> There are two major concerns we must consider when shelving code that is
>> ready for deploy:
>> 1) We do not write unnecessary code. Code only exists in the deploy
>> pipeline for a feature or defect fix that is ready to go out the door. We
>> view deployable code as an asset that should be handling requests as quickly
>> as possible.
>> 2) Un-merged code adds complexity. The Twitter code base is constantly
>> moving. Deploying code requires merging with the master branch which grows
>> in complexity as an undeployed branch sits idle.
>>
>> We currently use the changelog [1], @twitterapi [2], The API Announce List
>> [3], and the Dev Group [4] to inform developers of changes in hopes that
>> features will get used, and deprecations will be honored. I'd suggest any
>> developer with a long-running application to subscribe to the low noise,
>> only signal, API Announce mailing-list [3] to receive API updates as they
>> are released.
>>
>> Lastly, lets work together. Tell me what you developers need that we are
>> not currently providing. How can we better manage this communication? Which
>> method of notifications work best for you? Aside from transparency with API
>> changes, what else do you want to know?
>>
>> 1. http://apiwiki.twitter.com/REST+API+Changelog
>> 2. http://twitter.com/twitterapi
>> 3. http://groups.google.com/group/twitter-api-announce?hl=en
>> 4. http://groups.google.com/group/twitter-development-talk
>> 5.
>> http://groups.google.com/group/twitter-api-announce/browse_frm/thread/5822fbfd5ea857c6?hl=en
>> 6.
>> http://groups.google.com/group/twitter-api-announce/browse_frm/thread/68f2667f4e9842aa?hl=en#
>>
>> Keep the bytes flying,
>> Doug Williams
>> Twitter API Support
>> http://twitter.com/dougw
>>
>>
>>
>


-- 
“When nothing seems to help, I go look at a stonecutter hammering away at
his rock perhaps a hundred times without as much as a crack showing in it.
Yet at the hundred and first blo

[twitter-dev] Re: Article about my experiences deploying a Twitter Web app on Google App Engine Java

[Andrew Badera]

Error: Server Error The server encountered an error and could not complete
your request.

If the problem persists, please report  your
problem and mention this error message and the query that caused it.

On trying the app, the above is what I received ...

--ab
@andrewbadera


On Sat, Apr 11, 2009 at 12:30 PM, Dave Briccetti wrote:

>
> Perhaps this will save time for some of you.
>
>
> http://briccetti.blogspot.com/2009/04/my-first-scala-web-app-on-google-app.html
>
>

[twitter-dev] Article about my experiences deploying a Twitter Web app on Google App Engine Java

[Dave Briccetti]

Perhaps this will save time for some of you.

http://briccetti.blogspot.com/2009/04/my-first-scala-web-app-on-google-app.html

[twitter-dev] I get new follower mails, but I'm not followed

[Terry Jones]

Hi all

I've been getting a lot of mails telling me people are following me, but
when I click to take a look at the person I am not being followed by them.

At first I just assumed this was some kind of eventual consistency issue
with Twitter and that the web interface was showing the person with a
slightly out of date follower list.  When I check with the API I also don't
see the person as following me.

I've seen this (I guess) 20 times in the last few days.

I'm wondering what's going on. Is it just spammers (or others) creating
accounts, following many people, then immediately unfollowing? I also read
about the StalkDaily worm, so (if the worm exists and works as described) I
suppose if you wanted to infect people you could create new accounts and 
then just follow/unfollow people. See
http://kodespark.tumblr.com/post/95149076/the-stalkdaily-worm-on-twitter

Often twitter.com with show the person who's apparently following (but
isn't or no longer is) as following a high numeric number, but the number
of little icons of people they're following will be much much smaller.
That, I think, is just Twitter not having caught up with itself.

Anyway, I'm just commenting out loud, and wondering whether others are
seeing this. I imagine it must be widespread.

Terry

[twitter-dev] Re: "Failed to validate oauth signature or token" on status update post?

[Dominik Schwind]

Hm, I'm always calling write stuff, like /status/update, with POST -
actually I thought it's not possible to GET those calls. Still not
working on my end, even if I try around with those headers.

On Sat, Apr 11, 2009 at 2:44 PM, Bluespark  wrote:
>
> I have got my Python library working.  It simply is just changing the
> GET to post. When you encode your token and other items, you have to
> make sure you change this to a POST for the /status/update method.
>
> Calling status/update with a GET got me the 401 Authorization failed.
>
> This was a pretty easy fix, once you know where to look in your
> library.
>
> On Apr 11, 5:07 pm, jmathai  wrote:
>> I am having this problem as well.  GETs work fine but POSTs do not.  I
>> don't have any Authorization headers.
>>
>> On Apr 10, 10:37 am, Chen Jie  wrote:
>>
>>
>>
>> > I got a workaround for POST, I removed Authorization info in Header,
>> > then the POST request passed.
>>
>> > On Apr 10, 8:50 pm, max  wrote:
>>
>> > > I have the same problem since this morning, pretty strange, looked
>> > > over my code but I really don't see anything wrong.
>>
>> > > On Apr 10, 4:27 am, HSL  wrote:
>>
>> > > > Anyone else has the problem that posting a status update through OAuth
>> > > > gives the error: "failed to validate oauth signatre or token" since a
>> > > > few hours?



-- 
Dominik Schwind
www.lostfocus.de

Other ways to contact me on
www.dominikschwind.com

[twitter-dev] Oauth application directory

[Alberto Bajo]

Hi guys,

Is there any list or directory with applications implementing OAuth?

Thanks :)

--
Alberto Bajo
alber...@ideateca.com
http://filesocial.com

[twitter-dev] Messages with accented characters get truncated

[John]

I use a Windows function called InternetCanonicalizeUrl to encode
status messages before posting them to Twitter. It encodes é as %E9.
So for example, "café mocha" turns to "caf%E9%20mocha".

When I post this as a status update to Twitter, it shows up as
"caféocha". The "m" is dropped for some reason. Is this a known issue?

Thanks.

[twitter-dev] Re: A note on our API change policy

[Aaron Brazell]

Or better yet, API versioning!



On 4/11/09, Jesse Stay  wrote:
> Doug, can you guys do what Facebook is doing, and release it on a beta
> server somewhere beforehand so we can test it on our apps before you
> actually release it to the public?  A public staging server of some
> sort.  That will keep these surprises from happening, and we can start
> working out alerts to have in place when things might break our code
> that go on that beta server.  Best of all, it won't ever affect the
> end user.  Keep the releases on that server, then the releases out to
> the public on a timed release schedule.  It might take a little longer
> to get out to the public, but you'll have a much happier developer
> base and in turn a much happier end user by doing so.  That would be
> my number one suggestion.
> Do you guys do any tracking of Twitter itself for developers
> complaining about the API? I would also think you could gain some
> insight from that as well.
>
> @Jesse
>
> On Fri, Apr 10, 2009 at 12:04 PM, Doug Williams  wrote:
>
>> Twitter's development model is pragmatically agile where features enter
>> the
>> code base right alongside bug fixes. You can see this in our changelog
>> [1].
>> What is not clear from the log is that most of the code is written just
>> days
>> before.
>>
>> April 8th's rapid deprecation of the since parameter/If-Modified-Since
>> header (and to a lesser extent, the removal of undocumented HTTP POST
>> access
>> to accounts/verify_credentials) [5] caught a number of developers off
>> guard.
>> The criticism of this hasty change on the impact to hackers and businesses
>> alike was both valid and appropriate. The results from last month's survey
>> [6] lead us to believe that the use of this parameter was minimal and that
>> it was safe to capture performance gains through the deprecation. In
>> hindsight, our sample size was statistically insignificant because we made
>> a
>> mistake.
>>
>> It is apparent we need to make a change towards transparency. Openness
>> demands we give developers a clear line of communication when changes are
>> made that will break current functionality. While these changes are rare,
>> they do happen. As a result of this week's conversation, we will give a
>> minimum of 5 business days notice before we ship code that removes
>> currently
>> documented functionality. Two notable exceptions are critical security and
>> performance fixes.
>>
>> Five days may seem short notice but it is a compromise from our standard.
>> There are two major concerns we must consider when shelving code that is
>> ready for deploy:
>> 1) We do not write unnecessary code. Code only exists in the deploy
>> pipeline for a feature or defect fix that is ready to go out the door. We
>> view deployable code as an asset that should be handling requests as
>> quickly
>> as possible.
>> 2) Un-merged code adds complexity. The Twitter code base is constantly
>> moving. Deploying code requires merging with the master branch which grows
>> in complexity as an undeployed branch sits idle.
>>
>> We currently use the changelog [1], @twitterapi [2], The API Announce List
>> [3], and the Dev Group [4] to inform developers of changes in hopes that
>> features will get used, and deprecations will be honored. I'd suggest any
>> developer with a long-running application to subscribe to the low noise,
>> only signal, API Announce mailing-list [3] to receive API updates as they
>> are released.
>>
>> Lastly, lets work together. Tell me what you developers need that we are
>> not currently providing. How can we better manage this communication?
>> Which
>> method of notifications work best for you? Aside from transparency with
>> API
>> changes, what else do you want to know?
>>
>> 1. http://apiwiki.twitter.com/REST+API+Changelog
>> 2. http://twitter.com/twitterapi
>> 3. http://groups.google.com/group/twitter-api-announce?hl=en
>> 4. http://groups.google.com/group/twitter-development-talk
>> 5.
>> http://groups.google.com/group/twitter-api-announce/browse_frm/thread/5822fbfd5ea857c6?hl=en
>> 6.
>> http://groups.google.com/group/twitter-api-announce/browse_frm/thread/68f2667f4e9842aa?hl=en#
>>
>> Keep the bytes flying,
>> Doug Williams
>> Twitter API Support
>> http://twitter.com/dougw
>>
>> >
>>
>


-- 
-- 
Aaron Brazell
web:: www.technosailor.com
phone:: 410-608-6620
skype:: technosailor
twitter:: @technosailor

[twitter-dev] Re: "Failed to validate oauth signature or token" on status update post?

[Bluespark]

I have got my Python library working.  It simply is just changing the
GET to post. When you encode your token and other items, you have to
make sure you change this to a POST for the /status/update method.

Calling status/update with a GET got me the 401 Authorization failed.

This was a pretty easy fix, once you know where to look in your
library.

On Apr 11, 5:07 pm, jmathai  wrote:
> I am having this problem as well.  GETs work fine but POSTs do not.  I
> don't have any Authorization headers.
>
> On Apr 10, 10:37 am, Chen Jie  wrote:
>
>
>
> > I got a workaround for POST, I removed Authorization info in Header,
> > then the POST request passed.
>
> > On Apr 10, 8:50 pm, max  wrote:
>
> > > I have the same problem since this morning, pretty strange, looked
> > > over my code but I really don't see anything wrong.
>
> > > On Apr 10, 4:27 am, HSL  wrote:
>
> > > > Anyone else has the problem that posting a status update through OAuth
> > > > gives the error: "failed to validate oauth signatre or token" since a
> > > > few hours?

[twitter-dev] Re: [twitter-api-announce] A note on our API change policy

[Jesse Stay]

Doug, can you guys do what Facebook is doing, and release it on a beta
server somewhere beforehand so we can test it on our apps before you
actually release it to the public?  A public staging server of some
sort.  That will keep these surprises from happening, and we can start
working out alerts to have in place when things might break our code
that go on that beta server.  Best of all, it won't ever affect the
end user.  Keep the releases on that server, then the releases out to
the public on a timed release schedule.  It might take a little longer
to get out to the public, but you'll have a much happier developer
base and in turn a much happier end user by doing so.  That would be
my number one suggestion.
Do you guys do any tracking of Twitter itself for developers
complaining about the API? I would also think you could gain some
insight from that as well.

@Jesse

On Fri, Apr 10, 2009 at 12:04 PM, Doug Williams  wrote:

> Twitter's development model is pragmatically agile where features enter the
> code base right alongside bug fixes. You can see this in our changelog [1].
> What is not clear from the log is that most of the code is written just days
> before.
>
> April 8th's rapid deprecation of the since parameter/If-Modified-Since
> header (and to a lesser extent, the removal of undocumented HTTP POST access
> to accounts/verify_credentials) [5] caught a number of developers off guard.
> The criticism of this hasty change on the impact to hackers and businesses
> alike was both valid and appropriate. The results from last month's survey
> [6] lead us to believe that the use of this parameter was minimal and that
> it was safe to capture performance gains through the deprecation. In
> hindsight, our sample size was statistically insignificant because we made a
> mistake.
>
> It is apparent we need to make a change towards transparency. Openness
> demands we give developers a clear line of communication when changes are
> made that will break current functionality. While these changes are rare,
> they do happen. As a result of this week's conversation, we will give a
> minimum of 5 business days notice before we ship code that removes currently
> documented functionality. Two notable exceptions are critical security and
> performance fixes.
>
> Five days may seem short notice but it is a compromise from our standard.
> There are two major concerns we must consider when shelving code that is
> ready for deploy:
> 1) We do not write unnecessary code. Code only exists in the deploy
> pipeline for a feature or defect fix that is ready to go out the door. We
> view deployable code as an asset that should be handling requests as quickly
> as possible.
> 2) Un-merged code adds complexity. The Twitter code base is constantly
> moving. Deploying code requires merging with the master branch which grows
> in complexity as an undeployed branch sits idle.
>
> We currently use the changelog [1], @twitterapi [2], The API Announce List
> [3], and the Dev Group [4] to inform developers of changes in hopes that
> features will get used, and deprecations will be honored. I'd suggest any
> developer with a long-running application to subscribe to the low noise,
> only signal, API Announce mailing-list [3] to receive API updates as they
> are released.
>
> Lastly, lets work together. Tell me what you developers need that we are
> not currently providing. How can we better manage this communication? Which
> method of notifications work best for you? Aside from transparency with API
> changes, what else do you want to know?
>
> 1. http://apiwiki.twitter.com/REST+API+Changelog
> 2. http://twitter.com/twitterapi
> 3. http://groups.google.com/group/twitter-api-announce?hl=en
> 4. http://groups.google.com/group/twitter-development-talk
> 5.
> http://groups.google.com/group/twitter-api-announce/browse_frm/thread/5822fbfd5ea857c6?hl=en
> 6.
> http://groups.google.com/group/twitter-api-announce/browse_frm/thread/68f2667f4e9842aa?hl=en#
>
> Keep the bytes flying,
> Doug Williams
> Twitter API Support
> http://twitter.com/dougw
>
> >
>