<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 04/12/14 18:57, Kamil Kisiel wrote:<br>
    </div>
    <blockquote
cite="mid:CAEkhqB0ry-CkjTpXhjBGAhQhLbWwg3ryfXp-U3yQ0fG1Gjo2+w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Thu, Dec 4, 2014 at 9:53 AM, Edwin
            Mons <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:jsf@edwinm.ik.nu" target="_blank">jsf@edwinm.ik.nu</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div class="HOEnZb">
                <div class="h5">On 04/12/14 18:07, Kim Alvefur wrote:<br>
                  > On 2014-12-04 15:11, Kamil Kisiel wrote:<br>
                  >> On Thu, Dec 4, 2014 at 6:00 AM, Dave Cridland
                  <<a moz-do-not-send="true"
                    href="mailto:dave@cridland.net">dave@cridland.net</a><br>
                  >> <mailto:<a moz-do-not-send="true"
                    href="mailto:dave@cridland.net">dave@cridland.net</a>>>
                  wrote:<br>
                  >><br>
                  >><br>
                  >>     On 3 Dec 2014 21:11, "Kurt Zeilenga" <<a
                    moz-do-not-send="true"
                    href="mailto:kurt.zeilenga@isode.com">kurt.zeilenga@isode.com</a><br>
                  >>     <mailto:<a moz-do-not-send="true"
                    href="mailto:kurt.zeilenga@isode.com">kurt.zeilenga@isode.com</a>>>
                  wrote:<br>
                  >>     ><br>
                  >>     > 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?<br>
                  >>     ><br>
                  >>     > 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/>.<br>
                  >>     ><br>
                  >>     > 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.<br>
                  >>     ><br>
                  >><br>
                  >>     I think I agree with everything written
                  here. Sending the iq last<br>
                  >>     would be best, I think, though I
                  appreciate that's likely to be a<br>
                  >>     protocol bump.<br>
                  >><br>
                  >>     Dave.<br>
                  >><br>
                  >> That's how it was specified in version 0.2,
                  it seems it was changed to<br>
                  >> <fin/> in 0.3<br>
                  > I remember someone argued very persistently that
                  this change was needed<br>
                  > because their code had timeouts for iq requests
                  that could trigger if<br>
                  > there is rate limiting or a slow connection
                  before all the messages and<br>
                  > the iq-reply was received.<br>
                  ><br>
                  > Or something.  Personally I prefer having the
                  iq-result sent last, it<br>
                  > makes client code (Verse in my case) simpler.<br>
                  ><br>
                  <br>
                </div>
              </div>
              I believe that was Joe.  Nowhere in the XEP do I see a
              requirement that<br>
              the server should send back the IQ result (or error)
              immediately, just<br>
              that it has to answer the IQ, send back messages, and
              terminate with a<br>
              <message><fin/></message>.  The example
              seems to hint at sending the iq<br>
              result first, but nowhere does this claim you have to send
              back the iq<br>
              result before making an attempt to generate results
              internally.  Only<br>
              the examples hint that you should send back the iq result
              first, and<br>
              indeed that was the intended behaviour as discussed at the
              summit.<br>
              <span class="HOEnZb"><font color="#888888"><br>
                  Edwin<br>
                  <br>
                  <br>
                </font></span></blockquote>
          </div>
          <br>
        </div>
        <div class="gmail_extra">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.</div>
      </div>
    </blockquote>
    <br>
    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?)<br>
    <br>
    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.<br>
    <br>
    Edwin<br>
    <br>
    <br>
  </body>
</html>