I've written an IRC bot that can notify channels when new questions with a certain tag are posted. However, currently I'm polling the URL #{APIURL}questions?pagesize=100&fromdate=#{@_lastQuestionsDate}&tagged=node.js&key=#{KEY} every minute. I think that a streaming API would be better - easier to use, faster notifications and even (although that's probably not so important) less network traffic. How about implementing one? It could probably reuse the filter logic from the query API and apply it to all events.
Tell me more
×
Stack Apps is a question and answer site for
apps, scripts, and development with the Stack Exchange API. It's 100% free, no registration required.
|
|
|||||||||||||||||||
|
migrated from meta.stackoverflow.com Jan 5 '12 at 18:19
|
Developing this wouldn't be hard, but scaling it would be rough. The problem isn't bandwidth or cpu/ram (at least, not directly) but connections. I did some investigation of COMET (aka. Long Polling) approaches (like Twitter does) for V2.0, and didn't come away very confident. Web Hooks would be an alternative, but there are some serious DOS concerns there as (unlike with polling, long or otherwise) the client isn't dedicating any resources but we are. They're also much harder to consume than COMET approaches. Alternatives to polling are enticing, certainly, but I don't want to roll any out that we can't guarantee reasonable performance and availability for. |
|||||||||||
|