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 Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Nov 18, 3:25 pm, briantroy <brian.cosin...@gmail.com> 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 <jkalu...@gmail.com> 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 <brian.cosin...@gmail.com> 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
