Hi, > Letting the component act as a Jingle File Transfer receiver was my original > idea as well. However if you try to find any jingle ft implementations you'll > see that there basically aren't any. (To my knowledge there is Gajim, > Conversations and Swift (beta) and Swift is currently incompatible with Gajim > and Conversations because it uses :4 and this doesn't look like it will > change any time soon if you see the Gajim dev complaining about some missing > features in :4) And there is basically no library out there that has ready to > use jingle support. Meaning a component like that will probably not be > implemented any time soon. (It stopped me for almost a year.) > On the other side if your goal is to serve the uploaded files via HTTP I > don't see a reason why the file shouldn't be uploaded via HTTP as well. > Basically every platform has build in (or easy access to) methods for > uploading and downloading HTTP files.
Jingle File Transfer might be rarely implemented currently, because it is still in Experimental status. But a new (experimental) protocol (yet another one for file transfer), which will probably evolve as well, would certainly be implemented far less than Jingle FT and add more confusion to the question „how does file transfer work in XMPP“. > I don't see any upside of sticking with Jingle besides that it is somewhat > the "XMPP-way“. - Reuse of existing protocols - Less complexity for developers who already have to do a stretch to support the different file transfer protocols under a general API. - Different transports can be used for upload. Not only HTTP but also SOCKS5 and IBB. - Jingle (File Transfer) semantics can be reused, e.g. to cancel or reject a file upload or to communicate the hash, the file name, the file size, etc... I don’t know if Jingle (FT) is really suitable for the use case, but at a first glance it feels like the most obvious approach. — Christian
