On Thu, Dec 4, 2014 at 9:53 AM, Edwin Mons <j...@edwinm.ik.nu> wrote:
> On 04/12/14 18:07, Kim Alvefur wrote: > > On 2014-12-04 15:11, Kamil Kisiel wrote: > >> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland <d...@cridland.net > >> <mailto:d...@cridland.net>> wrote: > >> > >> > >> On 3 Dec 2014 21:11, "Kurt Zeilenga" <kurt.zeile...@isode.com > >> <mailto:kurt.zeile...@isode.com>> 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. > > > > I believe that was Joe. Nowhere in the XEP do I see a requirement that > the server should send back the IQ result (or error) immediately, just > that it has to answer the IQ, send back messages, and terminate with a > <message><fin/></message>. The example seems to hint at sending the iq > result first, but nowhere does this claim you have to send back the iq > result before making an attempt to generate results internally. Only > the examples hint that you should send back the iq result first, and > indeed that was the intended behaviour as discussed at the summit. > > Edwin > > > That seems a bit contradictory to me. If you can delay sending the result until all the messages have been sent, how does the <fin/> message solve the problem of timeouts waiting for the result iq? On the other hand if you are sending the iq result at the beginning to avoid the timeout, how do you indicate an iq error during the message stream? It doesn't seem clear what the answer is.
