zulip
api: Create a timeout mechanism for API calls ("short polling"?)
For certain advanced API applications, it will be useful to set out a timer for server requests. For example, I may want to only wait 5 seconds to get the next message in the stream, and if the message doesn't come, I want to do something else in real time like send a message myself or go to sleep for a bit, etc.
This would be a fairly technical project for somebody who understands long polling and sockets. The main file to modify would be https://github.com/zulip/python-zulip-api/blob/master/zulip/init.py
Once we had low-level support in our API bindings, we would probably add stuff to our BotHandler API to support things like scheduler bots and real-time game bots.
ping @cory2067
The other approach to consider for this would be to add support for our bots using some sort of asynchronous IO system.
I think I now understand the __init__.py API codepaths and would like to take this up.
From how I see it, we could implement this by providing do_api_query with some argument call_on_delay that gets executed as an async thread if n seconds have passed without a response from session.request.
We could then build on this to support it for out bot system.
Once we had low-level support in our API bindings, we would probably add stuff to our BotHandler API to support things like scheduler bots and real-time game bots.
I fail to see how things like scheduler bots would benefit from a request timeout mechanism. If I want to be notified in 15 minutes, it shouldn't depend on whether any incoming message arrives, right? If this is indeed independent, it would be great to merge an updated version of #5529, since I think that's one of the critical features out bot system is missing, together with proper state handling.
I keep trying to persuade folks not to use the threaded approach, but it's probably worth somebody trying it to prove me wrong, and if I'm wrong, so be it.
The request timeout mechanism would be useful in a single-threaded model. If you maintain a priority queue of upcoming events (easy to do with help from Python libraries), then it's easy to just do everything in a single thread. The only time you need to "short poll" is if you have something coming up in, say, five seconds, but you don't want to block incoming input.
