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 <jkalu...@gmail.com> 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 <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
