[Standards-JIG] Fiile transfer needs cancel feature?
justin-keyword-jabber.093179 at affinix.com
Fri Feb 3 22:02:13 UTC 2006
If we had this feature, I'd probably code the receiving client in such a way
that the accept dialog disables the "Accept" button and adds some text
somewhere saying, "(the sender has cancelled this request)". I would
definitely not remove the accept dialog from the screen, or otherwise try to
make it seem like the request never occurred.
Thus, the benefit would be to avoid a timeout when clicking on Accept.
Personally I don't think this is a big deal, but I'm not opposed if you want
to push for the feature.
On Friday 03 February 2006 08:05, Matt Tucker wrote:
> Hey all,
> We've run into what seems like a missing feature of JEP-0096 (or
> possibly JEP-0095).
> User A --> Offers file transfer to B
> User B --> Away from computer
> User A --> Decides sending raunchy video to co-worker is not the best
> career move so clicks cancel on the file transfer window. However,
> *JEP-0096 doesn't have a way to cancel a request before streaming
> User B --> Gets back to desk, sees file transfer request, hits accept.
> Nothing happens since A already cancelled request, probably has to wait
> for a timeout.
> Am I missing something, or do we need to add a way for the sender to
> issue a cancel before si starts? This isn't a hypothetical issue either
> -- it's something users have run into quite often in Spark. If there was
> a cancel command from A to B using the same stream ID, that seems like
> it would do the trick.
More information about the Standards