[Standards] XEP-0234 Jingle File Transfer 0.16
lancestout at gmail.com
Tue Jul 14 20:12:56 UTC 2015
The reasoning behind creating a FT:4 was to leverage the core semantics of Jingle versus continuing to reinvent them inside of FT to solve some of the remaining open items in the FT:3 spec.
(The idea here being that a general Jingle session management implementation should have a well lit path for how to use its existing session management tools & data to support file transfer.)
Thus, instead of a bundle of files inside a single Jingle Content, there is a separate Content per file. That solves the unresolved issues in FT:3 about how to add (and remove!) additional files to the transfer session while it is in progress. In FT:4, we use the standard Jingle content-* actions. A nice side effect is that it means that the files do not need to wait for each other to download over a single connection, the data can be sent in parallel via multiple connections.
However, in the process of editing and creating FT:4, the <request/> and <offer/> wrappers were removed, which appears to have removed the ability to request a file, but that case is still doable with FT:4. It now requires using core Jingle semantics instead of something inside FT itself. Namely, Jingle Contents may specify which side of the session is supposed to send data. This is an example of requesting files using FT:4
<iq to="friend at example.org" id="ft4" type="set">
<jingle xmlns="urn:xmpp:jingle:1" action="session-initiate" sid="jrk2o4oi24i3u24o">
<content name="file-request-1" creator="initiator" senders="responder">
<hash xmlns="urn:xmpp:hashes:1" algo="sha-1">65ea0164c91de2197956ed143099b90ff37d699e</hash>
<content name="file-request-2" creator="initiator" senders="responder">
<hash xmlns="urn:xmpp:hashes:1" algo="sha-1">da39a3ee5e6b4b0d3255bfef95601890afd80709</hash>
(Likewise for transfer offers, the Content should include `senders="initiator"` to indicate as such.)
I'm currently writing up patches to submit as a PR to add a section covering requesting files and the use of the content senders attribute, along with some additional examples and editorial fixes.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4115 bytes
Desc: not available
More information about the Standards