Some clients may do manual ping actions that already keep the connection
alive, or be run in environments where they otherwise know the
keep-alive conditions are different from the default.
Especially on mobile, we want to keep radio usage down, so doing
keep-alive in application logic is likely.
TVars and TChans expose the wrong interfaces (e.g. a user shouldn't be
able to add IQRequestTickets to the inbound channel or change the answer
recevied after sending an IQRequest).
IQs sent to the server may evoke responses with "from" attribute different
from the "to" attribute the request was sent to. Specifically, it might
be either empty, the JID of the server (that is, only domain part set) or either
the bare or full JID of the client.
This changes the return type of at least the following functions from IO Bool to IO (Either XmppFailure ())
* sendIQ
* sendIQ'
* answerIQ
* sendMessage
* sendPresence
IQResponseTimeout does not model an XMPP type but is instead an implementation specific signal that a user-set timeout has occured. Removing it keeps our representation closer to the defined protocol.
add IQSendError to keep the result of sendIQ' clear
rename reconnect to reconnectNow
* reconnect immediately
* function returns failure mode on error
add reconnect function
* retries when reconnect failes
* waits exponentially increasing amount of seconds between attemps
* returns last encountered error when all attempts fail
Stanza send functionality now directly sends the stanzas over the wire and returns appropriate notification whether the sent succeeded (as far as we can tell)
Philipp Balzarek
Stephen Paul Weber
Jon Kristensen