On 14.01.2015 20:51, Matthew Wild wrote: > 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.
Since there is a trend towards removing the <fin> message and reverting back to the former version, I'd like to point out, that what we see here is not an uncommon pattern in XMPP. Basically every time an entity requests an result set [1] you will have request → result1 → … → resultN → end of results I'd like to harmonize the protocol specifications in such cases and suggest that 'request' is always an IQ and 'end of results' is the corresponding IQ result to the request IQ. IQ get id=42 → result1 → … → resultN → IQ result id=42 Implementations can easily circumvent possible timeout errors while waiting for 'end of results' because of e.g. slow links or large result sets, by resetting the timeout waiting for the IQ result every time a result arrived. I don't like the idea of adding more complexity into a XEP/specification just because some implementations would otherwise need to change their code. I'd also like to discuss bundling the results. Leading to request → result(1-x) → … → result(y-N) → end of results This would mean less work for the (intermediate) processors of the stanzas and should be easily to implement. The only problem I see is, that if such a result would contain a 'forwarded message' (if we think of the xep313 case) of a size close to the lower bound of the maximum stanza size (10000 bytes IIRC), then bundling this message with another could result in a stanza that won't get routed, while sending each 'forwarded message' individually would cause no problems. - Florian 1; We have this case at least in xep13, xep313 and possible xep60
