[Standards-JIG] Fiile transfer needs cancel feature?
matt at jivesoftware.com
Fri Feb 3 22:20:20 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.
Yep, agreed. That's how we implement cancels right now ourselves.
> 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.
We've found it to be a pretty annoying UI issue so would love to see the
case included in the JEP. Combine this with automatic failover to IBB
from bytestreams (something we also need to post to standards-jig) and
XMPP will have the best file transfer protocol by far. :)
> 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
> > starts*.
> > 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