On 14 January 2015 at 17:12, Florian Schmaus <[email protected]> wrote: > On 04.12.2014 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 <[email protected] >>> <mailto:[email protected]>> wrote: 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. > > Exactly my experience. I recently started working on xep313 in Smack, > and if the iq response would signal the end of the messages the code > would become less complex. > > I also don't see how using a message compared to an iq response yields > any benefit when working on the xep313 client code. Only if your iq > response timeouts are hard-coded maybe, but this appears to be a bad > idea anyway.
Right. The issue was that the implementation Joe was referring to had an API for sending iq stanzas, and it automatically raised a timeout error if a response was not received within a certain period of time (globally configured), on the assumption that the result stanza might have been lost. This allows e.g. UI operations to not hang forever. I am also in favour of the original protocol (iq result to signal end of result set), but also I feel like the behaviour Joe described is a perfectly reasonable thing to do, and XEP-0313 would be a singular problem for it. I'll note that we don't have to revert to the old protocol flow to signal a failure in fulfilling the request. The iq response would still mean "query was ok and now in progress" as now, and we could add an attribute to <fin/> to indicate success or failure (i.e. the result stream ended prematurely). > Ideally xep313 implementations reset the timeout waiting for the final > iq response every time an archived message is received. > > As a side note: xep13 uses the same approach (see ยง 2.6, example 11 > and 12). Aha, thanks for pointing that out! Regards, Mattehw
