date:20091115



i concur - until we are sending back an error code if your status  
update was rejected (for being a duplicate or for going over 140  
characters), option #1 seems like the most prudent want to go about  
this.



Twitter has stated that providing a clear indication of when this has
occurred (I don't recall whether it was stated whether it will be an
error code per se or not) is "on the short list", but no ETA on a fix
has been given.

Until this is resolved, you basically have two options for trying to
detect it:

1) Keep track of the highest status ID you've encountered.  When a
status update is submitted, check the status ID in the response.  If  
the

update succeeded, the new ID will be higher than any old ID.  If it
failed, you'll get an older status (with an older, lower ID) instead.

2) Compare the text that you sent with the text you got back.  If
they're different, it failed - or Twitter did automatic URL shortening
or modified the text in some other manner.  If the new status is an
exact duplicate of the previous status, this would also falsely lead  
you

to believe that it had succeeded when it actually failed; depending on
your application, this may or may not be relevant.

Obviously, I consider method 1 to be the more reliable (although there
are certain race conditions in which it would fail, too), but it does
require you to keep that latest seen ID around and relatively
up-to-date.


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

[twitter-dev] Re: Empty reply from server on Streaming API?


There are two levels of blacklisting. One is a temporary band that
resets every few minutes. This one gives you 401 errors. Then there's
an IP black hole that is removed by an operator. Currently the IP
black hole sends a TCP RST, but we might might also null route you.
You can verify an IP block by attempting to connect from a different
network.

If you provide an account name, I can look through the logs and see
what happened. An IP address can also be helpful. In the absence of
these keys, I can only speculate as to what occurred.

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

On Nov 15, 12:54 am, Jim DeLaHunt  wrote:
> John:
>
> Thanks very much for the reply.
>
> On Nov 14, 8:30 pm, John Kalucki  wrote:
>
> > This sounds like you were ignoring HTTP error codes and eventually got
> > blacklisted. 
> > Consider:http://apiwiki.twitter.com/Streaming-API-Documentation#Connecting
>
> Hmm... I was launching single curl requests, making one connection
> then breaking it after max 3 seconds. I would then wait 6 minutes
> before trying to connect again.  I didn't record the HTTP result code
> I got back, but it seems that according to Streaming-API-
> Documentation#Connecting I was being tremendously conservative.  That
> doc recommends backing off for 10 to 240 seconds on an HTTP error code
> (>200); I always backed off for 360 seconds immediately, whether the
> HTTP error code was good or bad.
>
> How would backing off by *more* than the docs call for get me
> blacklisted?
>
> > You can tell for sure by turning off --silent and using -v to see
> > what's going on. You should be getting some sort of message back, or
> > absolutely nothing back. Those codes are not HTTP error codes, they
> > must be some curl artifact.
>
> Correct, the codes "6" and "52" are defined by curl. 
> Seehttp://curl.haxx.se/docs/manpage.html. Using -v and other curl
> options, I see clearly that what I'm getting back is "absolutely
> nothing back": 0 bytes in response to my HTTP query. (That's the
> meaning of the code "52".)
>
> For the last 6 hours, I've polled once per hour (once per 3600
> seconds), and this null response has not changed.
>
> The docs don't say how to confirm that I've been blacklisted. Any
> suggestions for how to confirm that? Nor do they say what to do if I
> am in fact blacklisted. They say that the blacklist lasts "an
> indeterminate period of time", so maybe they are implying I should
> just wait and the system will list the blacklist itself.
>
> The biggest issue, though, is to understand why I could have become
> blacklisted, when I backed off for 360 seconds after each attempt.
> Because right now, I don't know what I should do differently.
>
> Thanks again for the guidance.
>    --Jim DeLaHunt, Vancouver, Canada   �...@jdlh
>    Twanguages: a language census of Twitter 
> @twanguageshttp://jdlh.com/en/pr/twanguages.html
>
> > Tcpdump is also sometimes useful.
>
> > -John Kaluckihttp://twitter.com/jkalucki
> > Services, Twitter Inc.
>
> > On Nov 14, 6:13 pm, Jim DeLaHunt  wrote:
>
> > > Am I the only one seeing this? I call the Streaming API 10x/hour. For
> > > the last 23 hours or so, I've been getting bad responses every time.
>
> > > I use a cron job to call from the Linux shell:
>
> > > curl --user myid:mypassword --silent --fail --max-time 3 --retry 
> > > 0http://stream.twitter.com/1/statuses/sample.xml
>
> > > and I get usually a curl return code "(52) Empty reply from server",
> > > though sometimes "(6) name lookup timed out". Same thing happens when
> > > I ask for .json instead of .xml.
>
> > > The failures started at the rate of 1-2/hour on 2009/11/13 09:00h UTC
> > > (Friday early morning PST), though they became continuous as of
> > > 200/11/14 03:24h UTC (Friday evening PST), and remain continuous.
>
> > > Is anyone else calling this API and failing? Or succeeding? in the
> > > last 24 hours?
>
> > > Thank you,
> > >    --Jim DeLaHunt, Vancouver, Canada   �...@jdlh
> > >    Twanguages: a language census of Twitter   
> > > @twanguageshttp://jdlh.com/en/pr/twanguages.html

[twitter-dev] Re: 413 FULL head error on Streaming API


I believe I answered this question on Nov 12 (message 2) in this
thread.

http://groups.google.com/group/twitter-development-talk/tree/browse_frm/thread/c6046a1df338f0ae/1c4bf379d27abb32?rnum=1&q=413&_done=%2Fgroup%2Ftwitter-development-talk%2Fbrowse_frm%2Fthread%2Fc6046a1df338f0ae%2Fb886df7e063a8c44%3Flnk%3Dgst%26q%3D413%26#doc_d9c83205c406586b

There is no single role in the Streaming API that will allow that many
follows and track parameters.

-John




On Nov 12, 9:21 am, Julien  wrote:
> John,
>
> This is exactly what we post to your servers (I just hid the
> Authorization) :
>
> POST /1/statuses/filter.json HTTP/1.1
> Host: stream.twitter.com
> User-agent: TwitterStream
> Authorization: Basic X==
> Content-type: application/x-www-form-urlencoded
> Content-length: 13609
>
> follow=80706782,80706249,59397117,813276,1750351,1497,14303772,15640990,10630,1581511,794545,12,16718628,15351161,55033131,22207903,956501,16028823,982721,14100016,4411621,14615776,648563,26383279,21161414,10239,811350,9843812,16540939,20,25806143,15889416,10128922,13955972,31953,7337062,32653,1042361,26020994,1714051,7544012,309073,32063,14098218,33205299,1392281,664153,15328268,6717392,611823,15913,21169368,6892002,731253,7281962,14956807,5469512,13885092,36502008,15503041,5381582,26566923,2876271,14083455,18029701,1091741,8256162,34174320,16418101,17544169,22784949,5529162,813286,7136992,47685641,20935486,15864599,14712874,469163,14134376,13370272,1501,5973812,15133601,24338507,14454247,1748581,12858,13331942,1799511,10425502,24103,428333,10365,15279944,14229661,27663774,14692721,10226672,14363100,25694882,9536542,14418757,14114731,11900,15352135,18399826,22449663,7889672,25963448,5563012,66713497,1786041,19643660,17919393,14090674,14956888,25808898,59194896,2048141,15111776,16426292,45733,20201051,65973559,17781981,52680804,64409399,1367531,31132926,16450330,23853857,14075928,43856654,28156155,40197535,15773675,41112544,28174228,20526944,63407440,22802398,67899674,6017542,18120198,52589720,24855923,17829758,33233205,15945424,15954704,45075974,4404,17409240,22797985,14323759,26072066,614133,11881852,21655440,37879306,1652541,6368672,29925623,31353077,6821102,15876379,14634720,37405382,15838599,14790192,711303,23753940,59726910,17819913,18866407,17113231,17124895,1947301,5741722,27456531,1717,42033487,11856032,53372599,11857072,31114028,15996830,41075473,65904217,759251,23981347,14516048,27500565,16890969,16970248,15880642,16129920,42402819,45369197,31329385,5402612,13838562,14803917,8468872,14372478,65632985,14292132,80427603,38400130,22910295,77877070,48840381,3216921,612473,80713872,42056836,20153343,1705201,20924090,81391288,19438765,104203,14089573,4700381,7400702,33684457,37874853,14496232,7235522,7411552,71508034,15072502,33584794,15237935,81025521,22297824,7692692,18824787,18949452,7161542,22301030,27565488,14439930,1975321,1830491,46376581,19945693,23235489,14239496,3850041,22021097,43417156,12942,14162945,18159833,13827442,21645304,15708435,794928,15572963,11894422,456413,5579402,5990942,20399599,16297742,8085962,38961973,20631151,41375788,16416613,60334210,16705726,14305706,3128561,6893672,2860101,19039063,63810996,22651121,42860263,937961,50270097,36951816,1186,14613750,18799530,12974922,22543092,18991180,15251361,7408842,56458858,23530011,5567,48403197,586,15204168,17028306,2318591,20389644,7314182,14704003,14438790,42096373,45891150,15237382,60098511,27096075,19059514,14438014,4234581,15097328,50751569,246,54911372,770289,44011351,20194429,20365897,22540123,24203163,25489250,15533871,14166131,35136170,80766621,15915632,11268812,14768955,16901185,15888142,20132337,45537669,754978,19562029,32552821,33292459,14629669,14740219,1922861,4432431,19329393,16629431,31237480,41167154,7668952,16031518,28329367,81912095,26907579,15269523,15227791,15234407,41017380,21925979,21026837,11490952,16651978,15744222,17382456,14781982,22836661,22193651,19658936,24729040,14491138,17461978,44371159,32838392,36078825,3222731,24007848,29678507,15315785,22280679,23970108,41380057,34574635,42009631,59129082,35538270,66357651,66538952,38336343,21899223,25667617,78859670,67601095,67768214,14301002,68747982,16271343,16270679,19594811,40203798,22757239,46594911,80293100,13900252,23832022,19052717,71315517,78823450,33855080,43990220,17990812,45806824,9141622,27104736,32706664,39988586,16381061,20258912,74157758,52053604,74227685,43351209,76671588,59415820,21829544,37388407,15224126,26227858,18248645,38689604,65185176,21611204,22147157,14582043,13180972,47326062,61516762,33461621,14293310,76728008,72937694,14638581,69043094,34805346,16191323,75689974,30072246,45827487,75347542,74425788,80291874,80271800,71601293,51650188,56746527,18477121,22253558,16004911,82080333,24952459,33367205,15066838,6107422,972651,52725585,43062502,46277588,7076492,51509917,51413735,14994303,21879024,19394186,19058681,15494380,19697415,47326510,23135963,5793822,8921852,17133441,14302335,29014787,15633653,22205534,15192712,36116095,25098243,23484039,36751886,16

[twitter-dev] Twitter Search Timed Out


The uptime of twitter search {API} has degraded to the point of making
our client app useless.

Hoping @twitter finds the issue soon.

[twitter-dev] Re: Twitter Search Timed Out



hi mikawhite.

in the absence of actionable information, i'm not sure what you would  
like us to look into.  in order for us to help you out, please provide  
information such as which calls you are making, when you are seeing  
failures, and any other information you can provide us to correlate  
errors that may be occurring for you.


as a point of note, i have a script that issues a query against search  
every few minutes, and i haven't noticed significant failures.


thanks!



The uptime of twitter search {API} has degraded to the point of making
our client app useless.

Hoping @twitter finds the issue soon.



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

[twitter-dev] Re: Twitter Search Timed Out


Hi Raffi,

Three issues:

1) Search API returns 15 pages in 59+ seconds. Two weeks ago this was
less than 10 seconds. I sent @ej a tweet last week.


2) 503 Service Unavailable - increasing frequency {I'm now recording a
log to examine which searches this occurs with} {seems "to:xxx" is
most frequent fail}


3) "Unauthenticated API calls are deducted from the calling IP
address' allotment." - This makes sharing an IP address with other
users difficult. In my app, I will adjust my delays.

For future use of my app, say in a large company, will the company
need to have their IP whitelisted?


Thanks for Sunday support!

[twitter-dev] Re: Twitter Search Timed Out


Raffi,

Pls add this to a script - fails every time today.



http://search.twitter.com/search?q=to:mrskutcher

[twitter-dev] Re: Twitter Search Timed Out


1) Search API returns 15 pages in 59+ seconds. Two weeks ago this was
less than 10 seconds. I sent @ej a tweet last week.


just for reference - in the future, please file a bug on the google  
code tracker rather than sending @replies directly to twitter folk.   
we're better able to keep track of issues when recorded there.



2) 503 Service Unavailable - increasing frequency {I'm now recording a
log to examine which searches this occurs with} {seems "to:xxx" is
most frequent fail}


that's interesting.  i would suggest also looking at the streaming API  
rather than repeatedly accessing search.



3) "Unauthenticated API calls are deducted from the calling IP
address' allotment." - This makes sharing an IP address with other
users difficult. In my app, I will adjust my delays.


yeah - there is no other way to rate limit, i believe.


For future use of my app, say in a large company, will the company
need to have their IP whitelisted?



we would need to whitelist something, for a large company.  in  
addition, as mentioned above, i would suggest starting to look at the  
streaming API.


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

[twitter-dev] Re: Twitter Search Timed Out


Raffi, please note as soon as I tried the query below via the browser,
it slowly begins to work in the API.


On Nov 15, 10:25 am, mikawhite  wrote:

> http://search.twitter.com/search?q=to:mrskutcher

[twitter-dev] Re: Twitter Search Timed Out



personally, that's not how i would do it.

http://search.twitter.com/search.json?to=mrskutcher

works just fine for me.



Raffi,

Pls add this to a script - fails every time today.



http://search.twitter.com/search?q=to:mrskutcher




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

[twitter-dev] Re: Twitter Search Timed Out

Raffi,

Re: streaming API - I chatted with John about this. My take away is
the Streaming API isn't ready for a desktop client with an installed
base over several hundred users. Did I mis-understand?

I'd hope my installed base will eventually be tens of thousands.

On Nov 15, 10:26 am, Raffi Krikorian  wrote:
>
> that's interesting.  i would suggest also looking at the streaming API  
> rather than repeatedly accessing search.
>

[twitter-dev] Re: Twitter Search Timed Out

Details:

Calling "http://search.twitter.com/search.json?to=mrskutcher"; through
my client app did not work until I called same link via a browser.
Once called via the browser, it works in my client app.

Why?

On Nov 15, 10:29 am, Raffi Krikorian  wrote:
> personally, that's not how i would do it.
>
> http://search.twitter.com/search.json?to=mrskutcher
>
> works just fine for me.
>
>
>
> > Raffi,
>
> > Pls add this to a script - fails every time today.
>
> >http://search.twitter.com/search?q=to:mrskutcher
>
> --
> Raffi Krikorian
> Twitter Platform Team
> ra...@twitter.com | @raffi

[twitter-dev] Re: 413 FULL head error on Streaming API

2009-11-15 Thread Julien


Thanks John,

I am not sure I understand when you say "There is no single role in
the Streaming API that will allow that many  follows and track
parameters.", your documentation says :
"The default access level allows up to 200 track keywords and 400
follow userids. Increased access levels allow 80,000 follow userids
("shadow" role), 400,000 follow userids ("birddog" role), 10,000 track
keywords ("restricted track" role), and 200,000 track keywords
("partner track" role). Increased track access levels also pass a
higher proportion of statuses before limiting the stream."

Ryan Sarver said he granted us the "shadow" role yet (8 usersid),
we can track more than 400 userid...

What are our remaining options? Polling doesn't work (you block our
requests, and you say, (-but your doc says something different) that
we can use your streaming API.

Julien



On Nov 15, 7:01 am, John Kalucki  wrote:
> I believe I answered this question on Nov 12 (message 2) in this
> thread.
>
> http://groups.google.com/group/twitter-development-talk/tree/browse_f...
>
> There is no single role in the Streaming API that will allow that many
> follows and track parameters.
>
> -John
>
> On Nov 12, 9:21 am, Julien  wrote:
>
>
>
> > John,
>
> > This is exactly what we post to your servers (I just hid the
> > Authorization) :
>
> > POST /1/statuses/filter.json HTTP/1.1
> > Host: stream.twitter.com
> > User-agent: TwitterStream
> > Authorization: Basic X==
> > Content-type: application/x-www-form-urlencoded
> > Content-length: 13609
>
> > follow=80706782,80706249,59397117,813276,1750351,1497,14303772,15640990,106 
> > 30,1581511,794545,12,16718628,15351161,55033131,22207903,956501,16028823,98 
> > 2721,14100016,4411621,14615776,648563,26383279,21161414,10239,811350,984381 
> > 2,16540939,20,25806143,15889416,10128922,13955972,31953,7337062,32653,10423 
> > 61,26020994,1714051,7544012,309073,32063,14098218,33205299,1392281,664153,1 
> > 5328268,6717392,611823,15913,21169368,6892002,731253,7281962,14956807,54695 
> > 12,13885092,36502008,15503041,5381582,26566923,2876271,14083455,18029701,10 
> > 91741,8256162,34174320,16418101,17544169,22784949,5529162,813286,7136992,47 
> > 685641,20935486,15864599,14712874,469163,14134376,13370272,1501,5973812,151 
> > 33601,24338507,14454247,1748581,12858,13331942,1799511,10425502,24103,42833 
> > 3,10365,15279944,14229661,27663774,14692721,10226672,14363100,25694882,9536 
> > 542,14418757,14114731,11900,15352135,18399826,22449663,7889672,25963448,556 
> > 3012,66713497,1786041,19643660,17919393,14090674,14956888,25808898,59194896 
> > ,2048141,15111776,16426292,45733,20201051,65973559,17781981,52680804,644093 
> > 99,1367531,31132926,16450330,23853857,14075928,43856654,28156155,40197535,1 
> > 5773675,41112544,28174228,20526944,63407440,22802398,67899674,6017542,18120 
> > 198,52589720,24855923,17829758,33233205,15945424,15954704,45075974,4404 
> > ,17409240,22797985,14323759,26072066,614133,11881852,21655440,37879306,1652 
> > 541,6368672,29925623,31353077,6821102,15876379,14634720,37405382,15838599,1 
> > 4790192,711303,23753940,59726910,17819913,18866407,17113231,17124895,194730 
> > 1,5741722,27456531,1717,42033487,11856032,53372599,11857072,31114028,15 
> > 996830,41075473,65904217,759251,23981347,14516048,27500565,16890969,1697024 
> > 8,15880642,16129920,42402819,45369197,31329385,5402612,13838562,14803917,84 
> > 68872,14372478,65632985,14292132,80427603,38400130,22910295,77877070,488403 
> > 81,3216921,612473,80713872,42056836,20153343,1705201,20924090,81391288,1943 
> > 8765,104203,14089573,4700381,7400702,33684457,37874853,14496232,7235522,741 
> > 1552,71508034,15072502,33584794,15237935,81025521,22297824,7692692,18824787 
> > ,18949452,7161542,22301030,27565488,14439930,1975321,1830491,46376581,19945 
> > 693,23235489,14239496,3850041,22021097,43417156,12942,14162945,18159833,138 
> > 27442,21645304,15708435,794928,15572963,11894422,456413,5579402,5990942,203 
> > 99599,16297742,8085962,38961973,20631151,41375788,16416613,60334210,1670572 
> > 6,14305706,3128561,6893672,2860101,19039063,63810996,22651121,42860263,9379 
> > 61,50270097,36951816,1186,14613750,18799530,12974922,22543092,18991180,1525 
> > 1361,7408842,56458858,23530011,5567,48403197,586,15204168,17028306,2318591, 
> > 20389644,7314182,14704003,14438790,42096373,45891150,15237382,60098511,2709 
> > 6075,19059514,14438014,4234581,15097328,50751569,246,54911372,770289,440113 
> > 51,20194429,20365897,22540123,24203163,25489250,15533871,14166131,35136170, 
> > 80766621,15915632,11268812,14768955,16901185,15888142,20132337,45537669,754 
> > 978,19562029,32552821,33292459,14629669,14740219,1922861,4432431,19329393,1 
> > 6629431,31237480,41167154,7668952,16031518,28329367,81912095,26907579,15269 
> > 523,15227791,15234407,41017380,21925979,21026837,11490952,16651978,15744222 
> > ,17382456,14781982,22836661,22193651,19658936,24729040,14491138,17461978,44 
> > 371159,32838392,36078825,3222731,24007848,29678507,1531

[twitter-dev] Re: Twitter Search Timed Out - need for commercial accounts with dedicated resources

2009-11-15 Thread Dean Collins

I'd like to float an open discussion / dialog here.

 

"How many developers are getting to the point where they are choosing
NOT to develop on the Twitter platform"

 

 And

 

"If Twitter offered you a PAID commercial account which came with
dedicated access and dedicated support would this interest you".

 

 

 

For us personally we had a long serious discussion in the office this
week about dropping all of out Twitter functionality from our apps.

 

It's gotten to the stage it's just better to stick with Facebook
integration only instead of offering Twitter.

 

I'm trying to get a feel if we are the only developers feeling this
pain. Everytime I raise the issue with Twitter it's like - "Well we only
have so many people" or "This is a free service".

 

BULLSHIT, it costs me my time and energy developing for you and if it's
better spent elsewhere on a paid service then I'm happy to take my time
and energy.

 

 

 

What are your thoughts? 

 

 

 

 

 

Regards,

Dean Collins

Live Chat Concepts Inc

d...@livechatconcepts.com   

+1-212-203-4357   New York

+61-2-9016-5642   (Sydney in-dial).

+44-20-3129-6001 (London in-dial).

 

 

 

 

 -Original Message-
From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of
mikawhite
Sent: Sunday, November 15, 2009 10:30 AM
To: Twitter Development Talk
Subject: [twitter-dev] Twitter Search Timed Out

 

 

The uptime of twitter search {API} has degraded to the point of making

our client app useless.

 

Hoping @twitter finds the issue soon.

[twitter-dev] Re: Social Graph Methods: Removal of Pagination

2009-11-15 Thread Ryan Sarver


I just wanted to add some additional color to this as it didn't come
through well in our email announcement. The actual change is happening
Monday morning. Our email unfortunately said "today" as we were
planning to send it the day of, but we ended up sending it earlier to
give more notice and forgot to update the language.

To your point, our team specifically choose Monday morning so people
wouldn't have to be working on the weekend to fix things. We
definitely have heard everyone in the past and are trying to ensure
that all future changes like this happen early in the week and early
in the day.

Sorry again for the confusion, but we are listening and learning :)
thanks for your patience and hard work and hope everyone is having a
good weekend.

Best, Ryan

On Fri, Nov 13, 2009 at 10:45 PM, Tim Haines  wrote:
> Just like everyone knew the twitpocalypse was coming - but people still got
> burnt - even some high profile apps.  An earlier day in the week is prudent
> if it's a planned change.
>
> On Sat, Nov 14, 2009 at 7:14 PM, Josh Roesslein 
> wrote:
>>
>> Well I think most issues should have been long resolved by now.
>> Cursors have been live for a while now
>> and there was plenty of warning ahead of today. The turn off should
>> have no affect if you have ported to Cursors.
>>
>> On Fri, Nov 13, 2009 at 11:25 PM, Naveen Ayyagari 
>> wrote:
>> > I agree, friday is a poor time to make planned changes to the API...
>> >
>> > On Nov 13, 2009, at 11:58 PM, Jesse Stay wrote:
>> >
>> > I've already implemented this, but for future sanity, can you guys avoid
>> > doing these major updates on Fridays when we're all not focusing as much
>> > on
>> > work?  That way if there happen to be any bugs or problems our weekends
>> > aren't ruined.  This seems to be a frequent occurrence on the Twitter
>> > API.
>> > Thanks,
>> > Jesse
>> >
>> > On Fri, Nov 13, 2009 at 3:03 PM, Wilhelm Bierbaum 
>> > wrote:
>> >>
>> >> As previously announced by Alex Payne on September 24th (see
>> >> http://bit.ly/46x1iL), we're removing support for pagination from the /
>> >> friends/ids and /followers/ids methods.
>> >>
>> >> As of that time we set a hard deadline of October 26th, 2009. The
>> >> original date has passed as we tried to give all of our partners extra
>> >> time, but we are going to need to make the change now.
>> >>
>> >> At some point today, the "page" and "count" parameters will be ignored
>> >> by the /friends/ids and /followers/ids methods and we will only be
>> >> supporting cursors.
>> >>
>> >> Unfortunately, due to architectural considerations, cursor identifiers
>> >> are not predictable. This means that you will have to extract the next
>> >> and previous cursor identifiers from the results returned to you.
>> >>
>> >> For example, to get Obama's followers, we would first perform a GET
>> >> against:
>> >> http://twitter.com/followers/ids/barackobama.xml?cursor=-1
>> >>
>> >> Which returns XML similar to:
>> >> 
>> >>  
>> >>    30592818
>> >>    (... more ids ...)
>> >>  
>> >>  1319042195162293654
>> >>  -8675309
>> >> 
>> >>
>> >> To retrieve the next 5000 IDs, we would then perform a GET against:
>> >>
>> >>
>> >> http://twitter.com/followers/ids/barackobama.xml?cursor=1319042195162293654
>> >>
>> >> Note that cursors are signed 64-bit integers.
>> >>
>> >> Please refer to the documentation for our social graph methods for
>> >> more information:
>> >> http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends+ids
>> >> http://apiwiki.twitter.com/Twitter-REST-API-Method:-followers+ids
>> >>
>> >> Thanks!
>> >
>> >
>> >
>
>

[twitter-dev] Re: Twitter Search Timed Out - need for commercial accounts with dedicated resources


Dean, please start a new thread. Regarding my original thread topic,
support from twitter is awesome.

[twitter-dev] Re: 413 FULL head error on Streaming API


The default access levels are track 200 and follow 400.

Shadow increases follow to 80k, but leaves track at the default of
200.
TrackRestricted increases track keywords to 10k but leaves follow at
the default of 400.

All of the other mentioned roles do the same, they increase access on
one dimension, but leave the other dimension at the default. There is
no role currently available that increases both the track and the
follow limit. One could successfully argue that there should be such a
role. In the mean time, we suggest that the rare service that requires
both increased track and increased follow access obtain elevated roles
on two different accounts and connect twice. While this initially
appears annoying, it allows functionally partitioned predicate refresh
periodicity.

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


On Nov 15, 9:47 am, Julien  wrote:
> Thanks John,
>
> I am not sure I understand when you say "There is no single role in
> the Streaming API that will allow that many  follows and track
> parameters.", your documentation says :
> "The default access level allows up to 200 track keywords and 400
> follow userids. Increased access levels allow 80,000 follow userids
> ("shadow" role), 400,000 follow userids ("birddog" role), 10,000 track
> keywords ("restricted track" role), and 200,000 track keywords
> ("partner track" role). Increased track access levels also pass a
> higher proportion of statuses before limiting the stream."
>
> Ryan Sarver said he granted us the "shadow" role yet (8 usersid),
> we can track more than 400 userid...
>
> What are our remaining options? Polling doesn't work (you block our
> requests, and you say, (-but your doc says something different) that
> we can use your streaming API.
>
> Julien
>
> On Nov 15, 7:01 am, John Kalucki  wrote:
>
> > I believe I answered this question on Nov 12 (message 2) in this
> > thread.
>
> >http://groups.google.com/group/twitter-development-talk/tree/browse_f...
>
> > There is no single role in the Streaming API that will allow that many
> > follows and track parameters.
>
> > -John
>
> > On Nov 12, 9:21 am, Julien  wrote:
>
> > > John,
>
> > > This is exactly what we post to your servers (I just hid the
> > > Authorization) :
>
> > > POST /1/statuses/filter.json HTTP/1.1
> > > Host: stream.twitter.com
> > > User-agent: TwitterStream
> > > Authorization: Basic X==
> > > Content-type: application/x-www-form-urlencoded
> > > Content-length: 13609
>
> > > follow=80706782,80706249,59397117,813276,1750351,1497,14303772,15640990,106
> > >  
> > > 30,1581511,794545,12,16718628,15351161,55033131,22207903,956501,16028823,98
> > >  
> > > 2721,14100016,4411621,14615776,648563,26383279,21161414,10239,811350,984381
> > >  
> > > 2,16540939,20,25806143,15889416,10128922,13955972,31953,7337062,32653,10423
> > >  
> > > 61,26020994,1714051,7544012,309073,32063,14098218,33205299,1392281,664153,1
> > >  
> > > 5328268,6717392,611823,15913,21169368,6892002,731253,7281962,14956807,54695
> > >  
> > > 12,13885092,36502008,15503041,5381582,26566923,2876271,14083455,18029701,10
> > >  
> > > 91741,8256162,34174320,16418101,17544169,22784949,5529162,813286,7136992,47
> > >  
> > > 685641,20935486,15864599,14712874,469163,14134376,13370272,1501,5973812,151
> > >  
> > > 33601,24338507,14454247,1748581,12858,13331942,1799511,10425502,24103,42833
> > >  
> > > 3,10365,15279944,14229661,27663774,14692721,10226672,14363100,25694882,9536
> > >  
> > > 542,14418757,14114731,11900,15352135,18399826,22449663,7889672,25963448,556
> > >  
> > > 3012,66713497,1786041,19643660,17919393,14090674,14956888,25808898,59194896
> > >  
> > > ,2048141,15111776,16426292,45733,20201051,65973559,17781981,52680804,644093
> > >  
> > > 99,1367531,31132926,16450330,23853857,14075928,43856654,28156155,40197535,1
> > >  
> > > 5773675,41112544,28174228,20526944,63407440,22802398,67899674,6017542,18120
> > >  
> > > 198,52589720,24855923,17829758,33233205,15945424,15954704,45075974,4404
> > >  
> > > ,17409240,22797985,14323759,26072066,614133,11881852,21655440,37879306,1652
> > >  
> > > 541,6368672,29925623,31353077,6821102,15876379,14634720,37405382,15838599,1
> > >  
> > > 4790192,711303,23753940,59726910,17819913,18866407,17113231,17124895,194730
> > >  
> > > 1,5741722,27456531,1717,42033487,11856032,53372599,11857072,31114028,15
> > >  
> > > 996830,41075473,65904217,759251,23981347,14516048,27500565,16890969,1697024
> > >  
> > > 8,15880642,16129920,42402819,45369197,31329385,5402612,13838562,14803917,84
> > >  
> > > 68872,14372478,65632985,14292132,80427603,38400130,22910295,77877070,488403
> > >  
> > > 81,3216921,612473,80713872,42056836,20153343,1705201,20924090,81391288,1943
> > >  
> > > 8765,104203,14089573,4700381,7400702,33684457,37874853,14496232,7235522,741
> > >  
> > > 1552,71508034,15072502,33584794,15237935,81025521,22297824,7692692,18824787
> > >  
> > > ,18949452,7161542,22301030,27565488,14439930,1975321,1830491,4637658

[twitter-dev] Bad ssl certs on some servers for api.twitter.com/1 ?

2009-11-15 Thread Tim Haines

Hi there,

I'm doing some dev work and I'm getting occasional ssl errors when making
calls against api.twitter.com/1.  The most recent was posting to
favorites/create.

Is it possible some of the servers have bad certificates?  Or is it likely
I'm doing something very wrong?

Tim.

[twitter-dev] Re: Bad ssl certs on some servers for api.twitter.com/1 ?

2009-11-15 Thread John Adams


On Nov 15, 2009, at 1:16 PM, Tim Haines wrote:


Hi there,

I'm doing some dev work and I'm getting occasional ssl errors when  
making calls against api.twitter.com/1.  The most recent was posting  
to favorites/create.


Is it possible some of the servers have bad certificates?  Or is it  
likely I'm doing something very wrong?



All of our servers have the same certificates; We have had some people  
report a similar issue before and we verified all of the certificates  
at that time. I do know of people having validation issues when they  
don't have current versions of OpenSSL, a current Root CA bundle, or  
their code has problems processing chained SSL certificates.


Which program are you using to make requests against api.twitter.com?  
curl? Firefox?


Twitter's SSL certs are issued by RapidSSL/Equifax.
Make sure you have the proper root CA certs installed.

If you're using OpenSSL libraries directly, remember that OpenSSL  
ships without any Root CA certs installed.


Curl users will have similar problems as well -- you'll want to run mk- 
ca-bundle to get the proper ca-bundle installed.


The TTYtter developers have a script that pulls the current CA bundle  
from Mozilla, here:


http://www.floodgap.com/software/ttytter/mk-ca-bundle.txt

-john

[twitter-dev] Re: Bad ssl certs on some servers for api.twitter.com/1 ?

2009-11-15 Thread dean.j.robinson


This could possibly be related,

I recently switched from using https://twitter.com to https://api.twitter.com
and found that the majority of my cURL calls (via php) to the api
started failing, although no other parts of my function changed.

Out of curiosity I changed it to http://api.twitter.com and haven't
had the issue since.



On Nov 16, 10:46 am, John Adams  wrote:
> On Nov 15, 2009, at 1:16 PM, Tim Haines wrote:
>
> > Hi there,
>
> > I'm doing some dev work and I'm getting occasional ssl errors when  
> > making calls against api.twitter.com/1.  The most recent was posting  
> > to favorites/create.
>
> > Is it possible some of the servers have bad certificates?  Or is it  
> > likely I'm doing something very wrong?
>
> All of our servers have the same certificates; We have had some people  
> report a similar issue before and we verified all of the certificates  
> at that time. I do know of people having validation issues when they  
> don't have current versions of OpenSSL, a current Root CA bundle, or  
> their code has problems processing chained SSL certificates.
>
> Which program are you using to make requests against api.twitter.com?  
> curl? Firefox?
>
> Twitter's SSL certs are issued by RapidSSL/Equifax.
> Make sure you have the proper root CA certs installed.
>
> If you're using OpenSSL libraries directly, remember that OpenSSL  
> ships without any Root CA certs installed.
>
> Curl users will have similar problems as well -- you'll want to run mk-
> ca-bundle to get the proper ca-bundle installed.
>
> The TTYtter developers have a script that pulls the current CA bundle  
> from Mozilla, here:
>
> http://www.floodgap.com/software/ttytter/mk-ca-bundle.txt
>
> -john

[twitter-dev] Re: Bad ssl certs on some servers for api.twitter.com/1 ?

2009-11-15 Thread Adam Shannon


When you use HTTP over HTTPS you will never have trouble with (TLS)
certs because they
are never used for port 80 traffic.

On Sun, Nov 15, 2009 at 19:56, dean.j.robinson
 wrote:
>
> This could possibly be related,
>
> I recently switched from using https://twitter.com to https://api.twitter.com
> and found that the majority of my cURL calls (via php) to the api
> started failing, although no other parts of my function changed.
>
> Out of curiosity I changed it to http://api.twitter.com and haven't
> had the issue since.
>
>
>
> On Nov 16, 10:46 am, John Adams  wrote:
>> On Nov 15, 2009, at 1:16 PM, Tim Haines wrote:
>>
>> > Hi there,
>>
>> > I'm doing some dev work and I'm getting occasional ssl errors when
>> > making calls against api.twitter.com/1.  The most recent was posting
>> > to favorites/create.
>>
>> > Is it possible some of the servers have bad certificates?  Or is it
>> > likely I'm doing something very wrong?
>>
>> All of our servers have the same certificates; We have had some people
>> report a similar issue before and we verified all of the certificates
>> at that time. I do know of people having validation issues when they
>> don't have current versions of OpenSSL, a current Root CA bundle, or
>> their code has problems processing chained SSL certificates.
>>
>> Which program are you using to make requests against api.twitter.com?
>> curl? Firefox?
>>
>> Twitter's SSL certs are issued by RapidSSL/Equifax.
>> Make sure you have the proper root CA certs installed.
>>
>> If you're using OpenSSL libraries directly, remember that OpenSSL
>> ships without any Root CA certs installed.
>>
>> Curl users will have similar problems as well -- you'll want to run mk-
>> ca-bundle to get the proper ca-bundle installed.
>>
>> The TTYtter developers have a script that pulls the current CA bundle
>> from Mozilla, here:
>>
>> http://www.floodgap.com/software/ttytter/mk-ca-bundle.txt
>>
>> -john
>



-- 
- Adam Shannon ( http://ashannon.us )

[twitter-dev] Re: Twitter message with html entities get truncated

2009-11-15 Thread Brian Morearty

You wrote "So causes a problem for a cURL message. The message is truncated at the ampersand." This could be due to the fact that on UNIX-like systems (including Mac), the command line interprets the ampersand as "everything before this point should be run in the background." Anything after the ampersand is another command. If this is the problem, here is the solution: put the entire string in "quotes". curl "http://...&...&..."; Brian On Nov 11, 4:06 pm, mndasher wrote: > I store my content in a MySQL database. The website is using PHP. Data > fields are encoded so that html tags are using entities; i.e. = >

When I query the database I decode the entities, and then > strip the tags. That works fine. But some entities don't get > converted. So causes a problem for a cURL message. The message > is truncated at the ampersand. So I did a string replace where > becomes a space. So that solved one problem. But ampersand is still a > problem. Neither & or simply & work. The both result in a > truncated message. A string replace of & with 'and' seems to > work. But is kind of weird. > > I have also tried utf8_encode($message) but I don't see any difference > in the output or the result with the API. > > All of the API help and samples I have seen use a very simple message > example. I have not seen any help on how to format the actual > message. I saw some where that it should be UTF-8. Mostly the > messages are plain text, but these two characters cause problems. So > do quotes and single quotes as far as that goes. If I add slashes the > slashes come through in the final message. > > Is there any real help for these problems?

[twitter-dev] Re: "in reply to" links no longer appears in web interface

2009-11-15 Thread bassmanjase


OK, just checked this morning and "in reply to" links are back on the
website! Thanks for fixing the bug, twitter team! =)

On Nov 13, 2:00 pm, bassmanjase  wrote:
> Hi,
>
> I use twitter (@bassmanjase), and access it via the website and teh
> Echofon plugin for Firefox. I've just noticed today that the "in reply
> to" links no longer appear on the website, but they're still present
> in Echofon. It's possible that this change happened at the same time
> as the ReTweet "upgrade" - I saw the popup on my twitter home-page
> just a couple of days ago.
>
> I thought I'd mention it, since being able to see who someone is
> replying to is kind of helpful, esp since I have the bit.ly plugin
> installed which shows the original tweet when I hover over "in reply
> to". I can't do that any more, since the link is no longer there.
>
> There are quite a few users with this problem - just twitter-search
> "in reply to" and you'll get a decent number of hits.
>
> Cheers,
>
> Bassmanjase.

[twitter-dev] Re: 413 FULL head error on Streaming API

2009-11-15 Thread Julien


Thanks a lot John for this clear explaination.
Is it possible to have the following settings:
- superfeedr_foll as Shadow
- superfeedr_trac as TrackRestricted

That would truly be awesome. I will change our implementation so that
we use 2 different accounts for the 2 purposes.
Again, thx.

Julien


On Nov 15, 11:29 am, John Kalucki  wrote:
> The default access levels are track 200 and follow 400.
>
> Shadow increases follow to 80k, but leaves track at the default of
> 200.
> TrackRestricted increases track keywords to 10k but leaves follow at
> the default of 400.
>
> All of the other mentioned roles do the same, they increase access on
> one dimension, but leave the other dimension at the default. There is
> no role currently available that increases both the track and the
> follow limit. One could successfully argue that there should be such a
> role. In the mean time, we suggest that the rare service that requires
> both increased track and increased follow access obtain elevated roles
> on two different accounts and connect twice. While this initially
> appears annoying, it allows functionally partitioned predicate refresh
> periodicity.
>
> -John Kaluckihttp://twitter.com/jkalucki
> Services, Twitter Inc.
>
> On Nov 15, 9:47 am, Julien  wrote:
>
>
>
> > Thanks John,
>
> > I am not sure I understand when you say "There is no single role in
> > the Streaming API that will allow that many  follows and track
> > parameters.", your documentation says :
> > "The default access level allows up to 200 track keywords and 400
> > follow userids. Increased access levels allow 80,000 follow userids
> > ("shadow" role), 400,000 follow userids ("birddog" role), 10,000 track
> > keywords ("restricted track" role), and 200,000 track keywords
> > ("partner track" role). Increased track access levels also pass a
> > higher proportion of statuses before limiting the stream."
>
> > Ryan Sarver said he granted us the "shadow" role yet (8 usersid),
> > we can track more than 400 userid...
>
> > What are our remaining options? Polling doesn't work (you block our
> > requests, and you say, (-but your doc says something different) that
> > we can use your streaming API.
>
> > Julien
>
> > On Nov 15, 7:01 am, John Kalucki  wrote:
>
> > > I believe I answered this question on Nov 12 (message 2) in this
> > > thread.
>
> > >http://groups.google.com/group/twitter-development-talk/tree/browse_f...
>
> > > There is no single role in the Streaming API that will allow that many
> > > follows and track parameters.
>
> > > -John
>
> > > On Nov 12, 9:21 am, Julien  wrote:
>
> > > > John,
>
> > > > This is exactly what we post to your servers (I just hid the
> > > > Authorization) :
>
> > > > POST /1/statuses/filter.json HTTP/1.1
> > > > Host: stream.twitter.com
> > > > User-agent: TwitterStream
> > > > Authorization: Basic X==
> > > > Content-type: application/x-www-form-urlencoded
> > > > Content-length: 13609
>
> > > > follow=80706782,80706249,59397117,813276,1750351,1497,14303772,15640990,106
> > > >  
> > > > 30,1581511,794545,12,16718628,15351161,55033131,22207903,956501,16028823,98
> > > >  
> > > > 2721,14100016,4411621,14615776,648563,26383279,21161414,10239,811350,984381
> > > >  
> > > > 2,16540939,20,25806143,15889416,10128922,13955972,31953,7337062,32653,10423
> > > >  
> > > > 61,26020994,1714051,7544012,309073,32063,14098218,33205299,1392281,664153,1
> > > >  
> > > > 5328268,6717392,611823,15913,21169368,6892002,731253,7281962,14956807,54695
> > > >  
> > > > 12,13885092,36502008,15503041,5381582,26566923,2876271,14083455,18029701,10
> > > >  
> > > > 91741,8256162,34174320,16418101,17544169,22784949,5529162,813286,7136992,47
> > > >  
> > > > 685641,20935486,15864599,14712874,469163,14134376,13370272,1501,5973812,151
> > > >  
> > > > 33601,24338507,14454247,1748581,12858,13331942,1799511,10425502,24103,42833
> > > >  
> > > > 3,10365,15279944,14229661,27663774,14692721,10226672,14363100,25694882,9536
> > > >  
> > > > 542,14418757,14114731,11900,15352135,18399826,22449663,7889672,25963448,556
> > > >  
> > > > 3012,66713497,1786041,19643660,17919393,14090674,14956888,25808898,59194896
> > > >  
> > > > ,2048141,15111776,16426292,45733,20201051,65973559,17781981,52680804,644093
> > > >  
> > > > 99,1367531,31132926,16450330,23853857,14075928,43856654,28156155,40197535,1
> > > >  
> > > > 5773675,41112544,28174228,20526944,63407440,22802398,67899674,6017542,18120
> > > >  
> > > > 198,52589720,24855923,17829758,33233205,15945424,15954704,45075974,4404
> > > >  
> > > > ,17409240,22797985,14323759,26072066,614133,11881852,21655440,37879306,1652
> > > >  
> > > > 541,6368672,29925623,31353077,6821102,15876379,14634720,37405382,15838599,1
> > > >  
> > > > 4790192,711303,23753940,59726910,17819913,18866407,17113231,17124895,194730
> > > >  
> > > > 1,5741722,27456531,1717,42033487,11856032,53372599,11857072,31114028,15
> > > >  
> > > > 996830,41075473,65904217,759251,23981347,14516048,27500565,16890969,1697

[twitter-dev] Promoting got even easier on twitter

2009-11-15 Thread goTWEETme


Using Twitter is definitely the right way to social network - with the
new/up and coming sites capitalizing on twitter such as the "retweet,"
a new niche has emerged...the "pretweet" found exclusively at
http://www.goTWEETme.com.  This is a site that allows anyone to
request other twitter users to tweet their message.

For instance, if someone has a cause they are trying to promote like
(starving children in the USA) but they only have a few followers,
they can then go to http://www.goTWEETme.com and request
www.twitter.com/hungrychildren who has 10,000 followers to kindly
tweet out their message and/or site.

The pretweet is here and it's here to stay.

[twitter-dev] Re: Social Graph Methods: Removal of Pagination

2009-11-15 Thread Wilhelm Bierbaum


I apologize about the miscommunication. On twitter-api-announce
(http://bit.ly/3UQ0LU) I posted the date of Monday (11/16), but
unfortunately posted the wrong date on this group.

Sorry again for the confusion.

On Nov 15, 10:40 am, Ryan Sarver  wrote:
> I just wanted to add some additional color to this as it didn't come
> through well in our email announcement. The actual change is happening
> Monday morning. Our email unfortunately said "today" as we were
> planning to send it the day of, but we ended up sending it earlier to
> give more notice and forgot to update the language.
>
> To your point, our team specifically choose Monday morning so people
> wouldn't have to be working on the weekend to fix things. We
> definitely have heard everyone in the past and are trying to ensure
> that all future changes like this happen early in the week and early
> in the day.
>
> Sorry again for the confusion, but we are listening and learning :)
> thanks for your patience and hard work and hope everyone is having a
> good weekend.
>
> Best, Ryan
>
>
>
> On Fri, Nov 13, 2009 at 10:45 PM, Tim Haines  wrote:
> > Just like everyone knew the twitpocalypse was coming - but people still got
> > burnt - even some high profile apps.  An earlier day in the week is prudent
> > if it's a planned change.
>
> > On Sat, Nov 14, 2009 at 7:14 PM, Josh Roesslein 
> > wrote:
>
> >> Well I think most issues should have been long resolved by now.
> >> Cursors have been live for a while now
> >> and there was plenty of warning ahead of today. The turn off should
> >> have no affect if you have ported to Cursors.
>
> >> On Fri, Nov 13, 2009 at 11:25 PM, Naveen Ayyagari 
> >> wrote:
> >> > I agree, friday is a poor time to make planned changes to the API...
>
> >> > On Nov 13, 2009, at 11:58 PM, Jesse Stay wrote:
>
> >> > I've already implemented this, but for future sanity, can you guys avoid
> >> > doing these major updates on Fridays when we're all not focusing as much
> >> > on
> >> > work?  That way if there happen to be any bugs or problems our weekends
> >> > aren't ruined.  This seems to be a frequent occurrence on the Twitter
> >> > API.
> >> > Thanks,
> >> > Jesse
>
> >> > On Fri, Nov 13, 2009 at 3:03 PM, Wilhelm Bierbaum 
> >> > wrote:
>
> >> >> As previously announced by Alex Payne on September 24th (see
> >> >>http://bit.ly/46x1iL), we're removing support for pagination from the /
> >> >> friends/ids and /followers/ids methods.
>
> >> >> As of that time we set a hard deadline of October 26th, 2009. The
> >> >> original date has passed as we tried to give all of our partners extra
> >> >> time, but we are going to need to make the change now.
>
> >> >> At some point today, the "page" and "count" parameters will be ignored
> >> >> by the /friends/ids and /followers/ids methods and we will only be
> >> >> supporting cursors.
>
> >> >> Unfortunately, due to architectural considerations, cursor identifiers
> >> >> are not predictable. This means that you will have to extract the next
> >> >> and previous cursor identifiers from the results returned to you.
>
> >> >> For example, to get Obama's followers, we would first perform a GET
> >> >> against:
> >> >>http://twitter.com/followers/ids/barackobama.xml?cursor=-1
>
> >> >> Which returns XML similar to:
> >> >> 
> >> >>  
> >> >>    30592818
> >> >>    (... more ids ...)
> >> >>  
> >> >>  1319042195162293654
> >> >>  -8675309
> >> >> 
>
> >> >> To retrieve the next 5000 IDs, we would then perform a GET against:
>
> >> >>http://twitter.com/followers/ids/barackobama.xml?cursor=1319042195162...
>
> >> >> Note that cursors are signed 64-bit integers.
>
> >> >> Please refer to the documentation for our social graph methods for
> >> >> more information:
> >> >>http://apiwiki.twitter.com/Twitter-REST-API-Method:-friends+ids
> >> >>http://apiwiki.twitter.com/Twitter-REST-API-Method:-followers+ids
>
> >> >> Thanks!

[twitter-dev] Re: 413 FULL head error on Streaming API


Please request the additional access by whatever means you requested
your initial access.

-John

On Nov 15, 3:35 pm, Julien  wrote:
> Thanks a lot John for this clear explaination.
> Is it possible to have the following settings:
> - superfeedr_foll as Shadow
> - superfeedr_trac as TrackRestricted
>
> That would truly be awesome. I will change our implementation so that
> we use 2 different accounts for the 2 purposes.
> Again, thx.
>
> Julien
>
> On Nov 15, 11:29 am, John Kalucki  wrote:
>
> > The default access levels are track 200 and follow 400.
>
> > Shadow increases follow to 80k, but leaves track at the default of
> > 200.
> > TrackRestricted increases track keywords to 10k but leaves follow at
> > the default of 400.
>
> > All of the other mentioned roles do the same, they increase access on
> > one dimension, but leave the other dimension at the default. There is
> > no role currently available that increases both the track and the
> > follow limit. One could successfully argue that there should be such a
> > role. In the mean time, we suggest that the rare service that requires
> > both increased track and increased follow access obtain elevated roles
> > on two different accounts and connect twice. While this initially
> > appears annoying, it allows functionally partitioned predicate refresh
> > periodicity.
>
> > -John Kaluckihttp://twitter.com/jkalucki
> > Services, Twitter Inc.
>
> > On Nov 15, 9:47 am, Julien  wrote:
>
> > > Thanks John,
>
> > > I am not sure I understand when you say "There is no single role in
> > > the Streaming API that will allow that many  follows and track
> > > parameters.", your documentation says :
> > > "The default access level allows up to 200 track keywords and 400
> > > follow userids. Increased access levels allow 80,000 follow userids
> > > ("shadow" role), 400,000 follow userids ("birddog" role), 10,000 track
> > > keywords ("restricted track" role), and 200,000 track keywords
> > > ("partner track" role). Increased track access levels also pass a
> > > higher proportion of statuses before limiting the stream."
>
> > > Ryan Sarver said he granted us the "shadow" role yet (8 usersid),
> > > we can track more than 400 userid...
>
> > > What are our remaining options? Polling doesn't work (you block our
> > > requests, and you say, (-but your doc says something different) that
> > > we can use your streaming API.
>
> > > Julien
>
> > > On Nov 15, 7:01 am, John Kalucki  wrote:
>
> > > > I believe I answered this question on Nov 12 (message 2) in this
> > > > thread.
>
> > > >http://groups.google.com/group/twitter-development-talk/tree/browse_f...
>
> > > > There is no single role in the Streaming API that will allow that many
> > > > follows and track parameters.
>
> > > > -John
>
> > > > On Nov 12, 9:21 am, Julien  wrote:
>
> > > > > John,
>
> > > > > This is exactly what we post to your servers (I just hid the
> > > > > Authorization) :
>
> > > > > POST /1/statuses/filter.json HTTP/1.1
> > > > > Host: stream.twitter.com
> > > > > User-agent: TwitterStream
> > > > > Authorization: Basic X==
> > > > > Content-type: application/x-www-form-urlencoded
> > > > > Content-length: 13609
>
> > > > > follow=80706782,80706249,59397117,813276,1750351,1497,14303772,15640990,106
> > > > >  
> > > > > 30,1581511,794545,12,16718628,15351161,55033131,22207903,956501,16028823,98
> > > > >  
> > > > > 2721,14100016,4411621,14615776,648563,26383279,21161414,10239,811350,984381
> > > > >  
> > > > > 2,16540939,20,25806143,15889416,10128922,13955972,31953,7337062,32653,10423
> > > > >  
> > > > > 61,26020994,1714051,7544012,309073,32063,14098218,33205299,1392281,664153,1
> > > > >  
> > > > > 5328268,6717392,611823,15913,21169368,6892002,731253,7281962,14956807,54695
> > > > >  
> > > > > 12,13885092,36502008,15503041,5381582,26566923,2876271,14083455,18029701,10
> > > > >  
> > > > > 91741,8256162,34174320,16418101,17544169,22784949,5529162,813286,7136992,47
> > > > >  
> > > > > 685641,20935486,15864599,14712874,469163,14134376,13370272,1501,5973812,151
> > > > >  
> > > > > 33601,24338507,14454247,1748581,12858,13331942,1799511,10425502,24103,42833
> > > > >  
> > > > > 3,10365,15279944,14229661,27663774,14692721,10226672,14363100,25694882,9536
> > > > >  
> > > > > 542,14418757,14114731,11900,15352135,18399826,22449663,7889672,25963448,556
> > > > >  
> > > > > 3012,66713497,1786041,19643660,17919393,14090674,14956888,25808898,59194896
> > > > >  
> > > > > ,2048141,15111776,16426292,45733,20201051,65973559,17781981,52680804,644093
> > > > >  
> > > > > 99,1367531,31132926,16450330,23853857,14075928,43856654,28156155,40197535,1
> > > > >  
> > > > > 5773675,41112544,28174228,20526944,63407440,22802398,67899674,6017542,18120
> > > > >  
> > > > > 198,52589720,24855923,17829758,33233205,15945424,15954704,45075974,4404
> > > > >  
> > > > > ,17409240,22797985,14323759,26072066,614133,11881852,21655440,37879306,1652
> > > > >  
> > > > > 541,6368672,29925623,31353077

[twitter-dev] Re: Basic authentication with JQuery library ($.getJSON function)