> I concur with Matt. > > Track in the Streaming API is, in part, intended for > applications just like yours. Hit the Search API and use > track together to get the highest proportion of statuses > possible. The default track limit is intended for human > readable scale applications. Email me about elevated > track access for services.
I would use the Streaming API if I could, but now the problem is that my server side scripting language probably won't be able to use the Streaming API successfully ... My software hasn't been upgraded in years, and when it was first coded streaming data via http didn't even exist. The software has been upgraded once in a while over the past decade or so, but the last significant upgrade was more than 5 years ago and it didn't have anything added to allow streaming data access at that time, so I doubt it can handle this task now. I have an email request in to the current owners but I doubt they know how it works either. They never coded the original software or any of the upgrades. They just bought the software without possessing the expertise to understand the code, so they really don't know how it works internally either. My best guess is that it cannot write streaming data to a database as that data is transmitted, and that's what it needs it to do if I have any chance of using the Streaming API instead of a search. So I'll probably have to use some other software to accomplish this task. Any suggestions which software I should use to make this as fast and easy to code as possible? > It's possible that you are worrying about an unlikely > event. Sustained single topic statuses in the thousands > per minute are usually limited to things like massive > social upheaval, big political events, celebrity death, > etc. You may be correct, but to plan for the possibility that this may be bigger than expected is simply the way I do business. It doesn't make sense for me to launch a promo like this until I'm prepared for the possibilities, right? ____________________ Owkaye