On 4 Dec 2014, at 18:18, Curtis King <[email protected]> wrote: >> On Dec 4, 2014, at 10:10 AM, Edwin Mons <[email protected]> wrote: >> >> If you send back the iq result first, it will not be delayed further by all >> the result messages. Why would there be an error during the message stream >> that would prevent you from returning an otherwise valid 313 response (or in >> an extreme case terminating the stream and making the point of properly >> finishing the messages moot?) >> >> Most error cases will either happen before or at the moment when you >> actually start to find messages, e.g. authz issues or database issues. Once >> you start sending back messages, or know there aren't any for a particular >> query, you can always present a valid message stream including a fin with an >> appropriate rsm set a client can use to continue a query should it choose >> to. Note that the XEP allows you to return less items than the amount >> requested. > > The issue is in most cases once you know the query will be successful you > have the messages to send. So, we are saving less than a second. Doesn’t seem > much of a saving.
Much as I know it pains everyone when Isode folks agree with each other, I agree with both Curtis and Edwin - returning the iq as the sentinel lets us use iq responses in the way they were intended - anything else is circumventing them. I know that at the Summit, Joe spoke very strongly about the need for a sentinel message with an early-return iq, to avoid having to deal with special timeout code in a library he works with - after the last year of development/deployment experience I think we can now assert that moving the iq early effects the need for /more/ special-cased result-handling code, rather than less. If we continue with this patch, we will need to add error support to the sentinel, duplicating the iq semantics and requiring libraries to deal both with early iq errors and late message-based errors, and will need timeouts (if such things are necessary) to apply to both. I propose we roll back the sentinel and iq result handling to where they were originally, and have the iq terminate the results, either with a result (success) or error (failure). Would anyone support this, and does anyone oppose it? I’ve copied Joe as the previous opponent. (I note, as others have, that there are other XEPs that involve data-fetching by the target from remote services or databases (particularly user search), and could trigger issues in libraries that require immediate response to iqs.) /K
