[twitter-dev] ReTweeted to me not updating

[Rich]

Am I the only one seeing that the ReTweeted To Me API at
http://api.twitter.com/1/statuses/retweeted_to_me.xml hasn't been
updated since the 17th November but yet in the home_timeline I am
seeing new ReTweets to me?

Richard

[twitter-dev] Re: feature request: editing tweets

[Rich]

Strangely editing Tweets is disallowed by the API terms, even though
you can't physically edit them through the API.

I'd like the feature but I guess it could leave it open to abuse by
some people through the API.

On Nov 18, 9:10 pm, Olaf Doschke  wrote:
> I think it would make sense, if you allow deleting tweets and sending
> new ones, to also allow editing tweets. Even if you can't edit what
> has been forwarded to devices, in the web interface, desktop clients
> and smart devices this would make sense.
>
> Bye, Olaf.

[twitter-dev] Re: Lists API for Subscriptions

[Nik Fletcher]

Hi Guys

I've just opened a feature enhancement request with Twitter:

http://code.google.com/p/twitter-api/issues/detail?id=1213

If you've got any further details, please feel free to add these as
comments!

Cheers

-N

[twitter-dev] Re: Getting HTTP Code 503 Search Errors every 15 minutes

[Greg]

So how can I apply for a Search Whitelist?


On Nov 19, 12:17 am, Mark McBride  wrote:
> There are three different rate limits that apply to API usage
>
> 1) Your IP rate limit (used when making unauthenticated calls)
> 2) Your account rate limit (used when making authenticated calls)
> 3) Your search rate limit (used when making search calls)
>
> This is covered in the wiki, but it isn't highlighted, so it's easy to
> miss.  Check out this pagehttp://apiwiki.twitter.com/API-Overview,
> particularly the part about the API separation, and this 
> pagehttp://apiwiki.twitter.com/Rate-limiting, particularly the bit about
> search API rate limiting.
>
> Note that whitelisting for search is possible, but isn't given out as
> freely as whitelisting for the REST API.
>
>    ---Mark
>
> On Wed, Nov 18, 2009 at 6:47 PM, Greg  wrote:
> > Well the title explains it all. Every 15 minutes - my app gets 503
> > errors from the search api. Now reading the the documentation - this
> > would indicate a rate limit for Search - which is impossible due to
> > the whitelist for my IP. The Whitelist provides 20,000 API for a hour
> > - we make about 360 API calls per hour (Search refreshes every 20
> > seconds, calls 2 feeds) - so there is no way we would even come close
> > to the error.
>
> > The math:
>
> > Two Search API Feeds - running every 20 seconds = 6 times per minute *
> > 60 minutes = 360 calls.
>
> > Is this excessive?
>
> > Is anyone else experiencing this issue?
>
> > Thanks,
> > Greg

[twitter-dev] some of our users are getting partial timelines

[ronenpinko]

Some of our users are complaining they are missing tweets from their
timelines.
I went through status.twitter.com and found a post describing exactly
this critical bug,
though it's dated September 14 - http://status.twitter.com/page/9
(second one)

Perhaps it has returned or wasn't fixed entirely?

[twitter-dev] Twitter REST API Method: POST list members

[yarik_krm]

I have a problem with this function. When I set it with params, i got
the html page with error message:

Something is technically wrong.

Thanks for noticing _"we're going to fix it up and have things back to
normal soon.

Can you help me with it?
I'm using curl_exec() for it.

[twitter-dev] Re: Retweets and the Public Timeline

[Jeffrey]

I strongly urge and hope for the ability to see built-in retweets in
the user_timeline as this affects my application, since these tweets
are suddenly not visible.

If that is not possible, perhaps a new API could be created that would
allow an unauthenticated view of tweets and retweets?

[twitter-dev] Re: List creation updated (needs description param)

[Nelu Lazar]

I confirm this behavior, but I just added the "description" field to
the input form and it works like a charm. And I find it useful as
well.

- @NeluLazar


On Nov 19, 1:44 am, Rich  wrote:
> I can confirm this too, the lists are not being created without a
> description
>
> On Nov 19, 4:13 am, Naveen  wrote:
>
>
>
> > We are seeing this issue as well..
>
> > We create a list 
> > with:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-POST-lists
>
> > This is returning all valid data with an id for the list, which
> > indicates it was successfully created..
>
> > However when we try to get status for the list it is returning 404
>
> > Then we try to get the lists using
>
> >http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-GET-lists
>
> > And it is not returned in the result, the newly created list is also
> > not on the twitter website..
>
> > however if we include the description parameter(with empty content)
> > the list is created and returns expected data and does show up on the
> > twitter website..
>
> > There is a bug here...  The work around is to just include an empty
> > description field, which should not break anything in the future
> > either.
>
> > On Nov 18, 8:08 pm, Marcel Molina  wrote:
>
> > > The description parameter is not required to create a list.
>
> > > On Wed, Nov 18, 2009 at 3:57 PM, David  wrote:
> > > > I've been using the List api in my app, and just noticed that the POST
> > > > method to /:user/lists.:format returned the correct response, but
> > > > didn't actually create a list.
>
> > > > I've been following this api 
> > > > document:http://apiwiki.twitter.com/Twitter-REST-API-Method:-POST-lists
>
> > > > What I did notice was that the Add New List ui on Twitter.com has a
> > > > description field, and so I tried the same call with an additional
> > > > post param "description", and it worked.
>
> > > > The description param can be empty, but it is required to make this
> > > > call work.  Might be a bug?
>
> > > > Just a heads up for anyone who might be wondering.
>
> > > > DC
>
> > > --
> > > Marcel Molina
> > > Twitter Platform Teamhttp://twitter.com/noradio

Re: [twitter-dev] Re: feature request: editing tweets

[Michael Ivey]

That means you can't pull a tweet via the API, edit it, and then display it
on your site/app. You have to display the tweets as they are.

 -- ivey


On Thu, Nov 19, 2009 at 3:24 AM, Rich  wrote:

> Strangely editing Tweets is disallowed by the API terms, even though
> you can't physically edit them through the API.
>
> I'd like the feature but I guess it could leave it open to abuse by
> some people through the API.
>
> On Nov 18, 9:10 pm, Olaf Doschke  wrote:
> > I think it would make sense, if you allow deleting tweets and sending
> > new ones, to also allow editing tweets. Even if you can't edit what
> > has been forwarded to devices, in the web interface, desktop clients
> > and smart devices this would make sense.
> >
> > Bye, Olaf.
>

Re: [twitter-dev] Re: Getting HTTP Code 503 Search Errors every 15 minutes

[Mark McBride]

Send an email to a...@twitter.com with a description of your app, a
link to it if possible, and a brief justification for why you need
increased access.

   ---Mark

On Thu, Nov 19, 2009 at 3:18 AM, Greg  wrote:
> So how can I apply for a Search Whitelist?
>
>
> On Nov 19, 12:17 am, Mark McBride  wrote:
>> There are three different rate limits that apply to API usage
>>
>> 1) Your IP rate limit (used when making unauthenticated calls)
>> 2) Your account rate limit (used when making authenticated calls)
>> 3) Your search rate limit (used when making search calls)
>>
>> This is covered in the wiki, but it isn't highlighted, so it's easy to
>> miss.  Check out this pagehttp://apiwiki.twitter.com/API-Overview,
>> particularly the part about the API separation, and this 
>> pagehttp://apiwiki.twitter.com/Rate-limiting, particularly the bit about
>> search API rate limiting.
>>
>> Note that whitelisting for search is possible, but isn't given out as
>> freely as whitelisting for the REST API.
>>
>>    ---Mark
>>
>> On Wed, Nov 18, 2009 at 6:47 PM, Greg  wrote:
>> > Well the title explains it all. Every 15 minutes - my app gets 503
>> > errors from the search api. Now reading the the documentation - this
>> > would indicate a rate limit for Search - which is impossible due to
>> > the whitelist for my IP. The Whitelist provides 20,000 API for a hour
>> > - we make about 360 API calls per hour (Search refreshes every 20
>> > seconds, calls 2 feeds) - so there is no way we would even come close
>> > to the error.
>>
>> > The math:
>>
>> > Two Search API Feeds - running every 20 seconds = 6 times per minute *
>> > 60 minutes = 360 calls.
>>
>> > Is this excessive?
>>
>> > Is anyone else experiencing this issue?
>>
>> > Thanks,
>> > Greg
>

[twitter-dev] retweets aren't appearing in track streaming api

[Jim Gilliam]

My understanding is that the only way to get all the new retweets is through
the streaming API because they don't show up in search.   So I'm using the
track method, but I'm not seeing retweets come through.

Specifically, this: http://twitter.com/thekabira/status/5865706501 was
retweeted twice, but I didn't see it come through.  Old style retweets
continue to come through normally.

Jim Gilliam
http://act.ly/
http://twitter.com/jgilliam

[twitter-dev] "What are you doing?" => "What's happening?" changes

[Ryan Sarver]

Wanted to email everyone to point out the subtle, but important change
on twitter.com. Today we have rolled out an update that changes the
text above the "tweet box" from "What are you doing?" to say "What's
happening?". I could try to explain the reasons for the change, but
that's Biz's job :) You can read about the thinking behind the change
here: http://blog.twitter.com/2009/11/whats-happening.html

For each app, it's up to you if you want to make the change or make it
whatever you want -- we love the creativity. We will also be offering
translations for it and all of our other standard strings. If you
haven't seen the translations page on the wiki, check it out and keep
checking back in as we bring other languages online -
http://apiwiki.twitter.com/Twitter-String-Translations.

Read the post and let us know what you think of the change.

Ryan

Re: [twitter-dev] "What are you doing?" => "What's happening?" changes

[Cameron Kaiser]

> Wanted to email everyone to point out the subtle, but important change
> on twitter.com. Today we have rolled out an update that changes the
> text above the "tweet box" from "What are you doing?" to say "What's
> happening?". I could try to explain the reasons for the change, but
> that's Biz's job :) You can read about the thinking behind the change
> here: http://blog.twitter.com/2009/11/whats-happening.html

Still voting for "Type dammit" if you ever get around to it ;-)

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- The most valuable antiques are old friends. 

[twitter-dev] Re: retweets aren't appearing in track streaming api

[Jim Gilliam]

I figured out what's happening.  When "RT @thekabira" gets added to the
front of the tweet, it makes the tweet text longer than 140 characters, so
it then cuts off the rest of the tweet, which is what had "act" in it, so it
never shows up through the streaming api tracking for anything with "act" in
it.

So this tweet: "What’s the deal with the Climate Bill? RT new
#climategraphic , win a
prize! http://bit.ly/12H1X7 via @PhaedraEL 
http://act.ly/Rxt";

turns into this, when it's retweeted:

"RT @thekabira: What’s the deal with the Climate Bill? RT new
#climategraphic, win a prize! http://bit.ly/12H1X7 via @PhaedraEL http://ac...";

Jim

On Thu, Nov 19, 2009 at 12:05 PM, Jim Gilliam  wrote:

> My understanding is that the only way to get all the new retweets is
> through the streaming API because they don't show up in search.   So I'm
> using the track method, but I'm not seeing retweets come through.
>
> Specifically, this: http://twitter.com/thekabira/status/5865706501 was
> retweeted twice, but I didn't see it come through.  Old style retweets
> continue to come through normally.
>
> Jim Gilliam
> http://act.ly/
> http://twitter.com/jgilliam
>

[twitter-dev] Geotagging API

[Raffi Krikorian]

As you may have seen on the Twitter blog [1], geotagging is now  
available for all users and developers throughout Twitter's APIs.  
Specific geotagging methods have been added and existing formats  
expanded to accommodate this rich new information.


To get started developing with this API and sending geotweets, check out

http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0update

Geotweets now carry the geotag whenever available and whenever they  
appear in our REST, Search, and Streaming APIs.


Remember, geotagging is disabled by default on users' accounts.  
Encourage your users to enable it by sending them to their settings  
page [2].  From that page, a user can turn this feature on by checking  
the "Enable geotagging" checkbox.  Alternatively, we're also providing  
a mobile optimized geotagging settings page [3] that you can send them  
too as well.  As a developer, you can determine whether a user has  
enabled geotagging by calling the users/show method [4] or in any  
other  element returned by the REST API where a user object  
shows up -- just look for the geo_enabled flag.


For more hints on how to use geotagging, check out our Geotagging Best  
Practices page [5] where we have UX mock-ups, hints on how to best  
support user privacy, and more.


We're really excited about this feature!  And more is coming.

Go get lost.  We'll send help.

[1] http://blog.twitter.com/2009/11/think-globally-tweet-locally.html
[2] http://twitter.com/account/settings
[3] http://m.twitter.com/account/settings/geo
[4] http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-users%C2%A0show
[5] http://help.twitter.com/forums/26810/entries/78525

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

Re: [twitter-dev] Re: retweets aren't appearing in track streaming api

[Mark McBride]

Great!  I checked through the code paths, and they look solid on our end.

   ---Mark

On Thu, Nov 19, 2009 at 1:24 PM, Jim Gilliam  wrote:
> I figured out what's happening.  When "RT @thekabira" gets added to the
> front of the tweet, it makes the tweet text longer than 140 characters, so
> it then cuts off the rest of the tweet, which is what had "act" in it, so it
> never shows up through the streaming api tracking for anything with "act" in
> it.
>
> So this tweet: "What’s the deal with the Climate Bill? RT new
> #climategraphic, win a prize! http://bit.ly/12H1X7 via @PhaedraEL
> http://act.ly/Rxt";
>
> turns into this, when it's retweeted:
>
> "RT @thekabira: What’s the deal with the Climate Bill? RT new
> #climategraphic, win a prize! http://bit.ly/12H1X7 via @PhaedraEL http://ac
> ..."
>
> Jim
>
> On Thu, Nov 19, 2009 at 12:05 PM, Jim Gilliam  wrote:
>>
>> My understanding is that the only way to get all the new retweets is
>> through the streaming API because they don't show up in search.   So I'm
>> using the track method, but I'm not seeing retweets come through.
>>
>> Specifically, this: http://twitter.com/thekabira/status/5865706501 was
>> retweeted twice, but I didn't see it come through.  Old style retweets
>> continue to come through normally.
>>
>> Jim Gilliam
>> http://act.ly/
>> http://twitter.com/jgilliam
>
>

Re: [twitter-dev] Re: retweets aren't appearing in track streaming api

[Jim Gilliam]

It's great that most retweets are coming through, but the fact that it's
cutting off the end of tweets, making the track API not work if what you're
tracking happens to be in the last 15-20 characters of the tweet, is a
problem.   As it stands now, the only way for me to get at the retweets is
to query each individual tweet (like /statuses/retweets/5865706501.json),
over and over and over again to check.  Yuck!

Jim

On Thu, Nov 19, 2009 at 2:08 PM, Mark McBride  wrote:

> Great!  I checked through the code paths, and they look solid on our end.
>
>   ---Mark
>
> On Thu, Nov 19, 2009 at 1:24 PM, Jim Gilliam  wrote:
> > I figured out what's happening.  When "RT @thekabira" gets added to the
> > front of the tweet, it makes the tweet text longer than 140 characters,
> so
> > it then cuts off the rest of the tweet, which is what had "act" in it, so
> it
> > never shows up through the streaming api tracking for anything with "act"
> in
> > it.
> >
> > So this tweet: "What’s the deal with the Climate Bill? RT new
> > #climategraphic, win a prize! http://bit.ly/12H1X7 via @PhaedraEL
> > http://act.ly/Rxt";
> >
> > turns into this, when it's retweeted:
> >
> > "RT @thekabira: What’s the deal with the Climate Bill? RT new
> > #climategraphic, win a prize! http://bit.ly/12H1X7 via @PhaedraEL
> http://ac
> > ..."
> >
> > Jim
> >
> > On Thu, Nov 19, 2009 at 12:05 PM, Jim Gilliam  wrote:
> >>
> >> My understanding is that the only way to get all the new retweets is
> >> through the streaming API because they don't show up in search.   So I'm
> >> using the track method, but I'm not seeing retweets come through.
> >>
> >> Specifically, this: http://twitter.com/thekabira/status/5865706501 was
> >> retweeted twice, but I didn't see it come through.  Old style retweets
> >> continue to come through normally.
> >>
> >> Jim Gilliam
> >> http://act.ly/
> >> http://twitter.com/jgilliam
> >
> >
>

Re: [twitter-dev] Re: retweets aren't appearing in track streaming api

[Mark McBride]

Also note that the safer way to do what (I think) you're trying to do
is to use the retweets API
(http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets),
for example

curl -uyouruser:yourpassword api.twitter.com/1/statuses/retweets/5865706501.xml

   ---Mark

On Thu, Nov 19, 2009 at 2:08 PM, Mark McBride  wrote:
> Great!  I checked through the code paths, and they look solid on our end.
>
>   ---Mark
>
> On Thu, Nov 19, 2009 at 1:24 PM, Jim Gilliam  wrote:
>> I figured out what's happening.  When "RT @thekabira" gets added to the
>> front of the tweet, it makes the tweet text longer than 140 characters, so
>> it then cuts off the rest of the tweet, which is what had "act" in it, so it
>> never shows up through the streaming api tracking for anything with "act" in
>> it.
>>
>> So this tweet: "What’s the deal with the Climate Bill? RT new
>> #climategraphic, win a prize! http://bit.ly/12H1X7 via @PhaedraEL
>> http://act.ly/Rxt";
>>
>> turns into this, when it's retweeted:
>>
>> "RT @thekabira: What’s the deal with the Climate Bill? RT new
>> #climategraphic, win a prize! http://bit.ly/12H1X7 via @PhaedraEL http://ac
>> ..."
>>
>> Jim
>>
>> On Thu, Nov 19, 2009 at 12:05 PM, Jim Gilliam  wrote:
>>>
>>> My understanding is that the only way to get all the new retweets is
>>> through the streaming API because they don't show up in search.   So I'm
>>> using the track method, but I'm not seeing retweets come through.
>>>
>>> Specifically, this: http://twitter.com/thekabira/status/5865706501 was
>>> retweeted twice, but I didn't see it come through.  Old style retweets
>>> continue to come through normally.
>>>
>>> Jim Gilliam
>>> http://act.ly/
>>> http://twitter.com/jgilliam
>>
>>
>

[twitter-dev] Re: retweets aren't appearing in track streaming api

[Rich]

Sounds similar to my issue where the ReTweets To Me timeline isn't
being updated either

On Nov 19, 10:43 pm, Mark McBride  wrote:
> Also note that the safer way to do what (I think) you're trying to do
> is to use the retweets API
> (http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets),
> for example
>
> curl -uyouruser:yourpassword 
> api.twitter.com/1/statuses/retweets/5865706501.xml
>
>    ---Mark
>
>
>
> On Thu, Nov 19, 2009 at 2:08 PM, Mark McBride  wrote:
> > Great!  I checked through the code paths, and they look solid on our end.
>
> >   ---Mark
>
> > On Thu, Nov 19, 2009 at 1:24 PM, Jim Gilliam  wrote:
> >> I figured out what's happening.  When "RT @thekabira" gets added to the
> >> front of the tweet, it makes the tweet text longer than 140 characters, so
> >> it then cuts off the rest of the tweet, which is what had "act" in it, so 
> >> it
> >> never shows up through the streaming api tracking for anything with "act" 
> >> in
> >> it.
>
> >> So this tweet: "What’s the deal with the Climate Bill? RT new
> >> #climategraphic, win a prize!http://bit.ly/12H1X7via @PhaedraEL
> >>http://act.ly/Rxt";
>
> >> turns into this, when it's retweeted:
>
> >> "RT @thekabira: What’s the deal with the Climate Bill? RT new
> >> #climategraphic, win a prize!http://bit.ly/12H1X7via @PhaedraELhttp://ac
> >> ..."
>
> >> Jim
>
> >> On Thu, Nov 19, 2009 at 12:05 PM, Jim Gilliam  wrote:
>
> >>> My understanding is that the only way to get all the new retweets is
> >>> through the streaming API because they don't show up in search.   So I'm
> >>> using the track method, but I'm not seeing retweets come through.
>
> >>> Specifically, this:http://twitter.com/thekabira/status/5865706501was
> >>> retweeted twice, but I didn't see it come through.  Old style retweets
> >>> continue to come through normally.
>
> >>> Jim Gilliam
> >>>http://act.ly/
> >>>http://twitter.com/jgilliam

[twitter-dev] Banned For 1000s of friendship deletes/hr

[shiplu]

Hello,


Recently my IP was banned for "1000s of friendship deletes/hr".

friendship/delete method is a POST call. It should not have any limit.

All the calls were authenticated. So It should not hit any IP limit if its set.

Now It seems it hits a hidden limit. Twitter mentioned "1000s". So I
am still in dark. Still dont know what the exact number is.

Any idea how do I avoid such limit?


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

[twitter-dev] Re: Twitter-async PHP (oauth & basic) lib version 2 available

[Brooks Bennett]

Thanks so much for your hard work on this project.

I know it is thankless work, but this library has been a great help
for me.

Thanks!

On Nov 16, 7:10 pm, jmathai  wrote:
> Anyone using twitter-async can upgrade to the 2.0 version.
>
> http://wiki.github.com/jmathai/twitter-async/twitter-async-20-release...
>
> Changes
>
>    1. Added a new (preferred) API
>       You can now use get, post, delete, get_basic, post_basic and
> delete_basic
>    2. No longer asynchronous by default
>        Most people were using it synchronously and didn’t understand
> why you had to access a response parameter to ensure the call
> completed. useAsynchronous(true) should be used if you want to use it
> that way or hard code the default value in EpiTwitter.php
>    3. Revamped the exceptions
>    4. Added support for versioned URLs
>    5. Exposed response headers
>    6. Exception::getMessage() returns the response as raw text and not
> an array of messages
>        (even if debug is set to on)
>    7. Fixed lots and lots of bugs

Re: [twitter-dev] Banned For 1000s of friendship deletes/hr

[Mark McBride]

This isn't a rate limiting issue, it's an abuse issue.  What were you
doing that required 1000s of friendship deletes/hour?

   ---Mark

On Thu, Nov 19, 2009 at 4:02 PM, shiplu  wrote:
> Hello,
>
>
> Recently my IP was banned for "1000s of friendship deletes/hr".
>
> friendship/delete method is a POST call. It should not have any limit.
>
> All the calls were authenticated. So It should not hit any IP limit if its 
> set.
>
> Now It seems it hits a hidden limit. Twitter mentioned "1000s". So I
> am still in dark. Still dont know what the exact number is.
>
> Any idea how do I avoid such limit?
>
>
> --
> A K M Mokaddim
> http://talk.cmyweb.net
> http://twitter.com/shiplu
> Stop Top Posting !!
> বাংলিশ লেখার চাইতে বাংলা লেখা অনেক ভাল
> Sent from Dhaka, Bangladesh
>

[twitter-dev] Re: Streaming API

[briantroy]

It would be nice, however, if we could get the streaming API out of
ALPHA before the degrading of the search API begins... just saying...

Additionally, it would be helpful if Twitter would publish their EXACT
algorithm/method for matching tweets to track terms and
multiplexing... and here is why.
Given the current system for streaming your partners have to "undo"
the multiplexing and matching in order to effectively (accurately?)
provide the correct results.

Additionally, it should be pointed out that many services (mine
included) that offer multi-word exact match searches (because the old
Search API) will have to abandon support for those types of searches
(not good since they are perfectly valid for every other Social Media
search API) OR over subscribe to the track streaming API.

Example: I want to find "health care"

Using the streaming API I'll have no choice but to get every tweet
containing "health" OR "care" and then do the multi-word exact match
on the client side. This could cause me to be limited (sampled)
because too many tweets contain one of the individual words in my
multi-word search. As importantly, we will have to come up with a
solution to a single customer putting in too common a track word
(e.g., is) which would cause the total track streaming API to become
sampled.

My primary concern is that the new streaming API seems to have been
developed solely based on what is best for Twitter - without regard
for common partner/developer use cases. There is a TON of complexity
that has been shifted to the developer/client side of the API. If that
is what Twitter needs to do to maintain service and protect the
overall service I understand (I have to do the same), but given that
longer lead times are required (i.e., there is no way the current
search API should degrade until WELL AFTER the new API is out of BETA,
never-mind ALPHA).

Please understand - I simply want a stable production system (even if
it shifts a ton of complexity to the developer/client side) and until
the new one is ready and proven the "old" should not be degraded...

regards,

Brian Roy
justSignal

On Nov 18, 8:23 pm, John Kalucki  wrote:
> I wouldn't depend on Search returning high-throughput full-corpus
> results forever. Its eventual value is in providing relevance and
> ranking, just as every other search engine offers (Google, Bing, Y!,
> etc. etc.).
>
> I'm unaware of any firm dates, but this is overall story arc.
> Automated repetitive search should be largely via the Streaming API.
> The Search API is exceedingly expensive to provide in its current
> form, so I wouldn't expect overly-gracious transition periods.
> Instead, I'd expect various knobs to be turned steadily and
> progressively after a reasonable grace period.
>
> -John Kaluckihttp://twitter.com/jkalucki
> Services, Twitter Inc.
>
> On Nov 18, 3:25 pm, briantroy  wrote:
>
>
>
> > Had a feeling that would be the response. How long will the current
> > polling search API be alive (and supported)?
>
> > The demultiplexing of the status messages prevents a simple migration
> > path - as a matter of fact it requires a completely new architecture
> > for our collection from Twitter. As (or more) importantly it will
> > likely force changes that will impact downstream ETL/metadata
> > generation processes.
>
> > I do, however, understand the need (in terms of efficiency) to keep
> > concurrent connections optimized.
>
> > Can one be relatively assured that future iterations of the Search API
> > will have some degree of backwards compatibility?
>
> > regards,
>
> > Brian Roy
>
> > On Nov 18, 4:11 pm, John Kalucki  wrote:
>
> > > There's no need to open a connection per user. You should demultiplex
> > > the messages from a single connection or from a very small number of
> > > connections. 
> > > Seehttp://groups.google.com/group/twitter-development-talk/browse_frm/th...
>
> > > -John Kaluckihttp://twitter.com/jkalucki
> > > Services, Twitter Inc.
>
> > > On Nov 18, 2:46 pm, briantroy  wrote:
>
> > > > I have a question about the streaming API.
>
> > > > I am currently whitelisted for the standard search API on several IP
> > > > addresses. I'd like to begin moving to the streaming API (at least to
> > > > test) but am blocked by the "one connection per account" limit.
>
> > > > Is there a way to be whitelisted (by IP or credentials) to have
> > > > multiple connections? Is the assumed methodology that I would create a
> > > > single "stream" for 100's or 1000's of clients and somehow figure out
> > > > on my side which track term goes with which client?
>
> > > > Any help would be appreciated.
>
> > > > regards,
>
> > > > Brian Roy
> > > > justSignal.com

[twitter-dev] Retweet API launched to 100% of users

[Marcel Molina]

Back in August we announced plans to release the Retweet feature along with
an API to publish and consume retweets. Over the last few months we've been
gradually opening up the feature to more users as we performance test and
refine it. You can see some of the original announcement emails around
retweets here:
http://groups.google.com/group/twitter-api-announce/browse_thread/thread/1e07e332ec3d449d#
http://groups.google.com/group/twitter-api-announce/browse_thread/thread/08540da9d7d64c46#
http://groups.google.com/group/twitter-api-announce/browse_thread/thread/3641a248d555da20#
http://groups.google.com/group/twitter-api-announce/browse_thread/thread/46928276a4c78df2#

Today we've launched the feature to 100% of users. You can now consume
retweets via the /statuses/home_timeline resource, as well as all the
specialized retweet timelines. For backwards compatibility reasons we're
stripping retweets out of the friends_timeline resource as well as the
user_timeline resource. If you plan on implementing support for consuming
retweets from timelines, switch all instances of /statuses/friends_timeline
to /statuses/home_timeline.

All the relevant retweet documentation can be found here:
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweet
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_timeline
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweeted_by_me
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweeted_to_me
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets_of_me
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets

To those implementing this feature in your clients, I'd suggest taking some
UI cues from what we've done on Twitter.com:
http://s3.amazonaws.com/twitter_production/differentiating-retweets.png

Notice how the retweet by @ablegrape of @wblakegray's tweet is clearly
differentiated from the surrounding tweets with a distinctive retweet icon
and the "Retweeted by" label along the bottom. This is just one way of doing
it. Use whatever interface you think makes sense. What's important is
communicating to your users that the tweet they are seeing was shared with
them by someone they follow so they don't get confused by seeing tweets in
their timeline from people they aren't following.

We're just getting started with the retweet feature but we're happy with
this initial v1 we pushed out. We're really looking forward to seeing how
everyone works with this new API.

-- 
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio

[twitter-dev] French version of twitter.com launched: More translation strings now available

[Marcel Molina]

Twitter.com is now available in French: http://bit.ly/twitter-in-french

If you're looking to add a French version of your application, we've added
some of the translation
strings we're using to the translations page on the developer wiki:
http://apiwiki.twitter.com/Twitter-String-Translations

Hope some find it useful!

-- 
Marcel Molina
Twitter Platform Team
http://twitter.com/noradio

[twitter-dev] Re: Streaming API

[John Kalucki]

Brian,

We've been working almost exclusively on moving the Streaming API out
of Alpha status for many weeks now. We haven't launched a new user-
visible feature on Streaming for weeks. Instead, we're up to our
elbows in capacity plans, new machines, deploy scripts, latency-
shaving and so forth.

Note that the Streaming API has been fully available and considerably
lower latency than the Search API for all but perhaps 45 minutes since
Streaming launched back on April 15th. There are many household name
web properties that are using the Streaming API with no operational
complaints.

I don't understand how the algorithm will help much. The documentation
is already pretty explicit and you can observe how it works. I was
getting ready to copy and paste the ~20 lines of code in question
here, and I noticed a subtle bug. It's now two hours after I started
composing this and the code may have to wait for another day.

The Streaming API has been developed for a number of use cases, but a
feature-for-feature replacement for search it is not -- yet. However,
by volume, most automated repetitive searches are possible in the
Streaming API. Clearly we need to port a few more search features over
to streaming to allow some missing use cases and to reduce developer
complexity. Our plans and dates aren't fully formed -- which is why I
described this as the "overall story arc" -- this overall direction
should inform where to apply effort when multiple viable options
exist.

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

On Nov 19, 5:10 pm, briantroy  wrote:
> It would be nice, however, if we could get the streaming API out of
> ALPHA before the degrading of the search API begins... just saying...
>
> Additionally, it would be helpful if Twitter would publish their EXACT
> algorithm/method for matching tweets to track terms and
> multiplexing... and here is why.
> Given the current system for streaming your partners have to "undo"
> the multiplexing and matching in order to effectively (accurately?)
> provide the correct results.
>
> Additionally, it should be pointed out that many services (mine
> included) that offer multi-word exact match searches (because the old
> Search API) will have to abandon support for those types of searches
> (not good since they are perfectly valid for every other Social Media
> search API) OR over subscribe to the track streaming API.
>
> Example: I want to find "health care"
>
> Using the streaming API I'll have no choice but to get every tweet
> containing "health" OR "care" and then do the multi-word exact match
> on the client side. This could cause me to be limited (sampled)
> because too many tweets contain one of the individual words in my
> multi-word search. As importantly, we will have to come up with a
> solution to a single customer putting in too common a track word
> (e.g., is) which would cause the total track streaming API to become
> sampled.
>
> My primary concern is that the new streaming API seems to have been
> developed solely based on what is best for Twitter - without regard
> for common partner/developer use cases. There is a TON of complexity
> that has been shifted to the developer/client side of the API. If that
> is what Twitter needs to do to maintain service and protect the
> overall service I understand (I have to do the same), but given that
> longer lead times are required (i.e., there is no way the current
> search API should degrade until WELL AFTER the new API is out of BETA,
> never-mind ALPHA).
>
> Please understand - I simply want a stable production system (even if
> it shifts a ton of complexity to the developer/client side) and until
> the new one is ready and proven the "old" should not be degraded...
>
> regards,
>
> Brian Roy
> justSignal
>
> On Nov 18, 8:23 pm, John Kalucki  wrote:
>
> > I wouldn't depend on Search returning high-throughput full-corpus
> > results forever. Its eventual value is in providing relevance and
> > ranking, just as every other search engine offers (Google, Bing, Y!,
> > etc. etc.).
>
> > I'm unaware of any firm dates, but this is overall story arc.
> > Automated repetitive search should be largely via the Streaming API.
> > The Search API is exceedingly expensive to provide in its current
> > form, so I wouldn't expect overly-gracious transition periods.
> > Instead, I'd expect various knobs to be turned steadily and
> > progressively after a reasonable grace period.
>
> > -John Kaluckihttp://twitter.com/jkalucki
> > Services, Twitter Inc.
>
> > On Nov 18, 3:25 pm, briantroy  wrote:
>
> > > Had a feeling that would be the response. How long will the current
> > > polling search API be alive (and supported)?
>
> > > The demultiplexing of the status messages prevents a simple migration
> > > path - as a matter of fact it requires a completely new architecture
> > > for our collection from Twitter. As (or more) importantly it will
> > > likely force changes that will impact downstream ETL/metadata
> > >

[twitter-dev] Re: Retweet API launched to 100% of users

[Rich]

Excellent news Marcel, and also re-tweet support now submitted to
Apple in my App too :)

On Nov 20, 1:16 am, Marcel Molina  wrote:
> Back in August we announced plans to release the Retweet feature along with
> an API to publish and consume retweets. Over the last few months we've been
> gradually opening up the feature to more users as we performance test and
> refine it. You can see some of the original announcement emails around
> retweets 
> here:http://groups.google.com/group/twitter-api-announce/browse_thread/thr...http://groups.google.com/group/twitter-api-announce/browse_thread/thr...http://groups.google.com/group/twitter-api-announce/browse_thread/thr...http://groups.google.com/group/twitter-api-announce/browse_thread/thr...
>
> Today we've launched the feature to 100% of users. You can now consume
> retweets via the /statuses/home_timeline resource, as well as all the
> specialized retweet timelines. For backwards compatibility reasons we're
> stripping retweets out of the friends_timeline resource as well as the
> user_timeline resource. If you plan on implementing support for consuming
> retweets from timelines, switch all instances of /statuses/friends_timeline
> to /statuses/home_timeline.
>
> All the relevant retweet documentation can be found 
> here:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweethttp://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-home_t...http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retwee...http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses-retweets
>
> To those implementing this feature in your clients, I'd suggest taking some
> UI cues from what we've done on 
> Twitter.com:http://s3.amazonaws.com/twitter_production/differentiating-retweets.png
>
> Notice how the retweet by @ablegrape of @wblakegray's tweet is clearly
> differentiated from the surrounding tweets with a distinctive retweet icon
> and the "Retweeted by" label along the bottom. This is just one way of doing
> it. Use whatever interface you think makes sense. What's important is
> communicating to your users that the tweet they are seeing was shared with
> them by someone they follow so they don't get confused by seeing tweets in
> their timeline from people they aren't following.
>
> We're just getting started with the retweet feature but we're happy with
> this initial v1 we pushed out. We're really looking forward to seeing how
> everyone works with this new API.
>
> --
> Marcel Molina
> Twitter Platform Teamhttp://twitter.com/noradio