On Tuesday 07 September 2010 13:48:24 Peter Saint-Andre wrote: > On 8/23/10 3:34 AM, Yann Leboulanger wrote: > > On 08/19/2010 12:14 AM, Peter Saint-Andre wrote: > >> On 8/17/10 6:15 AM, Yann Leboulanger wrote: > >>> On 08/17/2010 02:03 PM, Matthew Wild wrote: > >>>> On 17 August 2010 12:52, Peter Saint-Andre<[email protected]> wrote: > >>>>> On 8/17/10 5:37 AM, Matthew Wild wrote: > >>>>>> Also I've had bad experience (as a user) with transfer resumption > >>>>>> thus > >>>>>> far... I think some clients just ignore the range, and send from 0, > >>>>>> causing the range-supporting recipient to receive the start of the > >>>>>> file twice. So either we make range support mandatory, or we need > >>>>>> some > >>>>>> way for the initiator to announce it. > >>>>> > >>>>> If anything, I'd prefer to remove ranges from XEP-0096. Do any > >>>>> clients support them? > >>>> > >>>> Without checking, I believe Miranda and Gajim do. > >>>> > >>>> Matthew > >>> > >>> Yep Gajim supports that to resume a transfer. > >> > >> Hi Yann, thanks for the confirmation. Is this feature useful? Does it > >> improve the user experience? Does it make file transfer more reliable? > >> Does it introduce complexities into the code? Is the cost worth the > >> benefit? Just curious. :) > >> > >> Peter > > > > Yep it's nice to be able to resume a file transfer when you're > > disconnected while transferring a big file. > > > > It doesn't introduce a lot of complexity. > > > > So I'm clearly in favor of keep such a functionality > > Yes, it seems fine and I am adding examples of ranged transfer to XEP-0234. > > The discovery mechanism in XEP-0096 seems a bit strange, though -- if > the sender includes <range/> then the recipient knows that it can > request a ranged transfer in the future (e.g., to restart a failed > session). But XEP-0096 didn't include a way to request a file, so how is > <range/> currently used in the wild? How does the sender know that the > recipient supports ranged transfers (e.g., start sending a file from an > offset after a failed transfer)? It seems to me that we need a service > discovery feature for ranged transfers in order for this to work reliably.
If by "in the future" you mean the iq-result sent by the receiver. :) The sender includes <range/> in the iq-set, indicating support. This means the recipient is allowed to specify a range to receive, in the iq-result that it sends back. The sender knows the recipient supports a ranged transfer because the recipient specified range values. -Justin
