On 2014-12-04 15:11, Kamil Kisiel wrote: > On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland <[email protected] > <mailto:[email protected]>> wrote: > > > On 3 Dec 2014 21:11, "Kurt Zeilenga" <[email protected] > <mailto:[email protected]>> wrote: > > > > How does the server, after it has responded to the IQ with a > type=result stanza, communicate errors in processing the query to the client > that might subsequently occur. What if the server is unable to send any > subsequent stanzas associated with the query? Is the server expected to hold > off sending the IQ response until it is reasonable assured that no subsequent > errors will occur? That is, to the time in which has compiled all the > stanzas to sends to the client and is ready to put them to XMPP stream? > > > > It seems to me that the IQ response really should come last so that the > server is able to indicate to the client whether or not is has successfully > completed the request or failed. If sent last, then there’s really no need > for a separate <fin/>. > > > > If the IQ response is not last, there there really needs to be some > method for the server to indicate that it’s not able to provide further > results. > > > > I think I agree with everything written here. Sending the iq last > would be best, I think, though I appreciate that's likely to be a > protocol bump. > > Dave. > > That's how it was specified in version 0.2, it seems it was changed to > <fin/> in 0.3
I remember someone argued very persistently that this change was needed because their code had timeouts for iq requests that could trigger if there is rate limiting or a slow connection before all the messages and the iq-reply was received. Or something. Personally I prefer having the iq-result sent last, it makes client code (Verse in my case) simpler. -- Kim "Zash" Alvefur
signature.asc
Description: OpenPGP digital signature
