Hi I've been developing this idea since almost a year now. Never got around to actually write some code until now.
2015-06-28 19:16 GMT+02:00 Christian Schudt <christian.sch...@gmx.de>: > Hi, > > I agree that XMPP is lacking such a specification („MUC File Transfer“, > „Offline File Transfer“). > > Maybe it’s even better, if the client and server could negotiate the > transport method first, so that the client could choose between „HTTP > Upload“, "SOCKS 5 Upload (XEP-0065)“ or „In-Band Upload (XEP-0047)“. > > What about the idea, that an XMPP server (component) acts as a Jingle File > Transfer receiver, so that a client and the server (component) negotiate > the File Transfer by means of XEP-0234 with just another (third) transport > method (HTTP), besides XEP-0260 and XEP-0261? > 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. I don't see any upside of sticking with Jingle besides that it is somewhat the "XMPP-way". > > That way clients could just reuse existing protocols and the sending > entity wouldn’t care if they are sending the file to another client or to a > server component. > Another advantage: HTTP upload might not always work (e.g. when behind a > HTTP proxy) and in this case the upload could fall back to IBB. > While this might pose a theoretical problem I find it hard to believe that there will be a lot of firewalls that allow XMPP connections (or arbitrary SOCKS connections) but no HTTP connections. > After successful upload, the client (or the server in behalf) could send > an XEP-0066 OOB message with the URL to all interested parties. The URL has > to be communicated of course, maybe as session-info. > I don't plan on specifying the distribution of the URL. It should be up to the user (client) to decide whether to use OBB or just sending the plain URL as text. Just providing the user with a possiblity to upload files and get a public HTTP address for them will also allow the usage in something like PEP avatars (they can contain HTTP URLs as source) cheers Daniel
