This style of handler is necessary for capturing result sets from
queries that use multiple messages to send the results instead of
in a single result stanza. Notably, XEP-0313 (MAM).
Note that using % in a string will _always_ perform the sting substitutions, because the strings are constructed before the function is called. So log.debug('%s' % expensiveoperation()) will take about the same CPU time whether or not the logging level is DEBUG or INFO. if you use , no substitutions are performed unless the string is actually logged
Waiting until the actual run step means that the handler is not
marked for deletion when checked in the __spawn_event() thread,
causing the callback to stay in the handler list.
Updated XMLStream to return True or False from removeHandler to indicate if the handler
existed and was removed.
Waiter handlers now unregister themselves after timing out.
* added stanza unhandled (unhandled iqs now reply with feature-not-implemented)
* added stanza exceptions (stanzas may now reply with exceptions when their handler raises an exception)
* sleekxmpp no longer spawns threads for callback handlers -- there are now two threads: one for handlers and one for reading. callback handlers can get results from the read queue directly with the "wait" handler which is used in .send() for the reply catching argument.
