On Tuesday 07 August 2007 10:29 pm, Sergei Golovan wrote: > On 8/8/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > > 3. IBB (XEP-0047) is a great fallback if all else fails. > > IBB couldn't be a great fallback. It's very inconvenient to use in the > fillowing circumstances (which don't so rarely happen): > > 1) JID A offers file to JID B and waits for the answer (note that to > answer, B must return an IQ result, and the time interval might be > quite long). > > 2) JID A decides to abort file transfer and closes the > file-transfer-window-or-whatever-GUI-she-has. > > 3) JID B replies with IQ result, but > a) File transfer doesn't start (A aborted it) > b) JID B will NEVER know about A aborted file transfer and > will stuck with file-receiving-GUI forever since there's no mechanism > to recognize this unwilling to transfer. > > Wouldn't it better to add an extra query from B to A after stream > negotiation part? If A doesn't want to send file anymore, she will > return error to B.
I wouldn't put this at the IBB level. A negotiation timeout will work well enough there. The problem you speak of, which does indeed happen a lot, has more to do with the SI exchange. If someone offers a file, and you take too long to accept, they may cancel the file offer and you'll never know. This will happen regardless of whether you use S5B or IBB or anything. In Psi we solved this by adding a timeout to the accept phase. The sender must begin the S5B negotiation within 30 seconds of the receiver pressing "Accept". If the timeout expires, a dialog is presented to the receiver that says something along the lines of "the sender probably cancelled". I believe Jive added a protocol extension so that the receiver can know if a file transfer was cancelled. Maybe it is worth documenting. -Justin
