I'd like to collect suggestions for "cancelling" an in-process iq transaction.
We have an application where the result (success or failure) of an iq get/set query can take a long time to determine. Long enough that we would like the initiator to be able to cancel if it decides it doesn't want to wait, or wants to modify the query and try again. Currently we do this with a higher-level application protocol. The initiator sends an iq, and the receiver validates and responds just based on whether the iq is valid. This result includes a handle to the request in an application-specific element. It then goes to work and "dials back" by sending a *new* iq back to the original initiator which the results in a 'set' marked by the same application-specific handle so the initiator can match up the data. In the meantime, the initiator can also send a new iq using that same handle to cancel (or modify) its initial request. This is quite a bit of extra state (and code) however, so it would be nice to have a better way. Any ideas? All I've been able to come up with is to overload the iq id field. XMPP Core says that it's optional for the id to be unique, so what happens if it's reused for an iq while the earlier transaction is still pending. Could this be used (depending on application-specific elements in the body) to cancel or modify the earlier request, or is that spec abuse? It does make it impossible to tell at the XMPP level which iq stanza a result/error corresponds to. Curious, -r _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
