GNOME Bugzilla – Bug 141569
File transfer support
Last modified: 2007-08-11 08:35:26 UTC
Filetransfer support http://www.jabber.org/jeps/jep-0096.html
*** Bug 173071 has been marked as a duplicate of this bug. ***
Created attachment 54478 [details] [review] First patch OK, so this patch does nothing, it is just here so I have somewhere to put my first workings. This patch includes 2 modules (gossip-jabber-ft.[ch] and gossip-jabber-ft-utils.[ch]). These modules basically include functions to create the xml required with Loudmouth and the utilities to convert the content to base64. This work is NOT hooked up to any of the other code yet but it will compile.
Also, note, the last patch makes use of inband data file transfer only, not the SOCKS work that GeertJan is doing.
Created attachment 54700 [details] [review] Second Patch OK, so this patch does the following: * Allows you to initiate the send a file request (not configurable which file). * Receives a request to be sent a file. * Adds events to the event manager and acts like the subscription stuff where it will pop a dialog when clicked on from the system tray. What this patch doesn't do: * Send a response to the file transfer initiation request (either allow or deny). * Handle any of the actual transfer back end. So based on this patch most of the foundation and classes/types are in place so it is just a case of joining up the allow/deny part of a request and doing the back end actual IBB / SOCKS work.
Created attachment 54841 [details] [review] Fourth Patch OK, this is the latest installment :) I have tested this with Gajim, GAIM and PSI, so far it seems to work well across all of those except GAIM - which does something quite different - uses Service Discovery. I think it might be a good idea to implement something here, since this is used to tell quering clients what we can do, e.g. what features we support. We need this for the GnomeMeeting stuff and Transports (if that ever gets revived). Some Changes: * Now we handle errors a lot better and if the transfer fails to start up because the other side is not supported then we get those errors. * Also if the other side denies our send file request, we get a message dialog to say this. * We can now deny inbound requests too. * Now we use the File Chooser to select the file we want to send. * Improved the file transfer request dialog to show the file size in the correct units. Todo: * I have emailed Geert-Jan asking for his SOCKS back end work so we can try and get that in (I have seen nothing of it so I don't know how far he has got). * Don't use the "file-transfer-error" event for the declined requests, instead use a "file-transfer-declined" event. * Use the roster instead to show flashing file icon (or something??) * Get the back ends working (IBB and SOCKS).
OK, I have committed the intrastructure that is needed for this bug. So far, you can receive requests but ONLY decline them. More work is needed to support the back end file transfer JEPs.
What is the current status of this bug ? Jep-0096 has many drawbacks, here are some of them. * Inability to establish bytestream connection, if only receiver has public ip. * It is impossible to change the streamhost, when transfer is already started. * Most of the users don't have real ips and are forced to use proxies. Proxies are unreliable and most of them prevent transfers, when one of the resources contains nonascii characters. Using several proxies + service discovery verification can help a little, but IMO it is not for gossip. * jep-0065 requires full jids of both peers, which make it useless with some transports. * There are no error messages for active streams. When recepient lose connection to proxy, there is no way to tell that to sender. I think it will be much better if Gossip has Jingle File Transfer instead. Psi is working on that as a SoC application.
Is anyone working on this?
No, but I would love for someone to finish it for me. I started it and the main infrastructure is there, all that is left to do is the file encoding and decoding. Are you interested?
Yep, how can I get started?
Cool!! Well, the basic stream initiation and negotiation standard is here: http://www.jabber.org/jeps/jep-0096.html This is the part I have mostly written. The 0096 JEP says that there are two standards you can use to do file transfer. 1: http://www.jabber.org/jeps/jep-0065.html 2: http://www.jabber.org/jeps/jep-0047.html (and they _should_ be supported in that order) Personally I think #2 is easier but the problem with it is, that all traffic is inband and hence goes via the server. I would be great if you could do both, but at this point, either would be superb! Have a look at protocols/jabber/gossip-jabber-ft*.[ch] to see what has already been done.
Are these likely to be deprecated in favour of Jingle sharing? Also can you Jabber me, please? I want to work on this regardless but I'm going to need a bit of help. I don't even know where to check out any source code.
Crap, forgot to add: xmpp:alex@weej.com
I have added you Alex, and yet it is likely that Telepathy will have its own method for file sharing we can use. But until then, it would be nice to have something usable. I can help on this. I am sure there are others too.
Hi Martyn No outstanding subscription requests... :S
I can't figure this out for toffee. How are you supposed to associate a bytestream (whether it is SOCKS5, in-band or otherwise) to a specific file transfer SI? From what I can gather, it seems you just do the SI handshake then ... wait for the next bytestream that happens to come from the initiating JID. This seems total crack, and I can't believe that it is truly the case. This is driving me up the wall, somebody please save me!
OK I think I've figured it out thanks to a section in JEP-95: http://www.jabber.org/jeps/jep-0095.html#impl-stream
Hi Alex, do you still work on this?
Michael No, I pretty much gave up. It was a lot more complicated than I thought. Feel free to take it.
I think it's all happening in Telepathy, right now.
There is no spec for file transfer in telepathy yet, but it will come.
It'd still be nice to have file transfer working with the loudmouth backend.
Agreed Vincent and should not be too much work to get it working for that backend.
I have file receiving via 0065 for loudmouth. Need a bit some time to finish the rest of it and integrate it into gossip, so the patch will be attached soon. There is some code for 0047 in gossip, but this is a different method for FT.
Created attachment 85467 [details] [review] xep0065 based file transfers for loudmouth
Created attachment 85468 [details] [review] simple use of above patch with gossip There is no progress indicator and event notifications.
I have reviewed the Gossip patch and I tried it out this evening, it works really nicely! Now all that remains is to get the new Loudmouth API added :) Thanks for doing this Dimitur! Micke, what do you think?
Hm, I haven't had the time to look into this closely but it adds a lot of API to Loudmouth. I'm not sure how much of this needs to be exported to the application developer (all of the new header files?).
lm-bs-session.h is the only header that needs to be exported. I'll add one more function for tracking transfer progress: void lm_bs_session_set_progress_function (LmBsSession *session, LmBsProgressFunction function, gpointer user_data, GDestroyNotify notify); lm_bs_session_set_progress_function
Ok, great, then I can consider adding it with a clause that it might change in the near future as I'm currently in the process of reworking the API for creating extensions and also make it possible to add features like this outside of Loudmouth itself.
Created attachment 85846 [details] [review] Some cleanups and making valgrind happy New version of attachment 85468 [details] [review]: (if it is not commited yet, otherwise I'll patch it on latest svn/git)
Created attachment 85847 [details] [review] Same as above for loudmouth > ------- Comment #30 from Mikael Hallendal 2007-04-05 11:36 UTC > ------- Ok, great, then I can consider adding it with a clause that > it might change in the near future as I'm currently in the process of > reworking the API for creating extensions and also make it possible > to add features like this outside of Loudmouth itself. This is great. One thing that could be considered as well is the similar blocks of code that now appear in lm-connection.c and lm-bs-client.c It will be good to move all socket related functionallity in in lm-sock.c, or a new class .
In Loudmouth HEAD most of that code has been moved out of LmConnection into LmSocket (lm-socket.c) which is a GObjectified socket (I'm considering dropping this and use the socket code from Libsoup though). In HEAD I have also added a layer between LmConnection and LmSocket that I call LmTransport. The idea is that it doesn't have to be a socket that is used to send the things (could be a unix socket, a pipe, something different).
I am going to mark this as fixed. We have file transfer support now, it needs improving but the basics are there. I just want to thank Dimitur Kirov for writing the patches, superb work, many thanks for getting this to us!