Version: (using KDE KDE 3.1.1) Installed from: Debian testing/unstable Packages It sure would be nice if I could use kget to transfer bittorrent files. In particular, I'd like to see: Dragging a link (http://a.b.org/blah/foo/something.torrent) into kget would download the .torrent file, then start the bittorrent transfer (up/download) process. Dragging a .torrent file on the local host into kget would just start the bittorrent transfer process. Implementing this might mean another field in the ui indicating upload as well as download rates. It would also mean that I could leave my kget window up and it would continue to upload bittorrent files after everything had been downloaded. I'd sure prefer to have kget be my single kde utility for managing all my batch/large file transfers, regardless of specific protocol (ftp, http, bittorrent, ssh). It just seems to be the right thing to do.
This would be super cool if it was implemented.
Yes I thougt about this today as well. It could be implemented even KDE-wide. One could just drag a .torrent file to your Desktop and a kioslave (or KGet) would download the .torrent file, and if the user wishes, redirect to a bittorrent: protocol, which takes care of downloading the file. I am not experienced enough in KDE stuff to be able to exactly describe how this would be handled.
The BitTorrent protocol can be integrated into KDE by using KMLDonkey which is available from http://extragear.kde.org Considering this I'm suggesting closing this bug as WONTFIX, unless the KGet authors are wanting to support BitTorrent in KGet as well nevertheless. In such case KMLDonkey's own library allows such an integration and could thus offer a solution for this as well.
I politely disagree. This bug is about seamless *integration* of bittorrent without requiring any further apps. KMLDonkey however requires MLDonkey and so on. It would be very cool if *ANY* kde user can simply click on a bittorrent file in konqueror and it would download just like a normal file. KDE would be the first desktop to do this but such support by the Desktop Environment is necessary IMO to leverage the full power of this protocol. Imagine you would need to install additional software to view jpg files. Would jpg files be used in web pages just as frequently as they are today? Certainly not. So, if SVG is integrated, why not bittorrent. Even if not other Desktop Environment supports this right now, it would at least allow to distribute files (i.e. new KDE releases) to KDE users in a more economic way.
Subject: Re: please handle bittorrent protocol You have an interesting interpretation of the term "seamless integration", KMLDonkey does integrate quite seamless as of now in that it integrates the features by MLDonkey into the common KDE frameworks, easy to access for any other KDE application. If you really think KDE should get its own *native implementation* of the bittorrent protocol you better first look at the discussion the inclusion of KMLDonkey to KDE Extra Gear sparked http://lists.kde.org/?t=106337428100003
Interesting discussion. And I certainly share some of the doubts about integrating a true file sharing software. I think bittorrent (and this bug) is about something different though: It's not a "true" file sharing protocol, because you cannot search on other peoples computers for files. It's rather like FTP. You can download a file and (in contrast to FTP) distribute the server load ("give sth. back while downloading"). FTP is part of KDE/KGet as well. I agree however that a file sharing app like KMLDonkey shouldn't be directly a part of KDE. Besides the legal issues mentioned in the mailing-list, file sharing apps are too often subject to changes. Some protocols/networks get outdated, some new ones get popular. Bittorrent is really different, because it can't promise i.e. to "find more files", because it's just a simple download protocol. And that's what this bug is about. So I think KMLDonkey or Apollon are really different beasts. And we're just talking about bittorrent download which I consider like FTP downloads. So this big has still a valid point IMO.
I agree, bittorrent support should be part of kget, independantly from kmldonkey which imply too much dependances. But this feature should be configurable, to be able to limit the upload (and download) bandwitch used, as bittorrent can easily saturate it.
I totally agree with Comment #6. A Bittorrent implementation can't tempt one into piracy nor can it help find pirated stuff in any way. I't just a tool with a vast potential. That potential can be "enabled" by implementing it seamlessly into KDE, and activating it by default. Hint: Don't forget to let root disable it systemwide and enable it on a per-user or per-group basis easily.
I keep being shocked by all these crazy paradigm collisions, so here's my official position on the issue, for the record: http://lists.kde.org/?l=kde-devel&m=107376738719596&w=2 Implementing BitTorrent as a KIO slave is downright silly. Trying to force it into KGet is probably possible, but probably also not a good idea. BitTorrent just isn't a simple download protocol, and needs an interface more adapted to its particular paradigm. Personally, I blame the BitTorrent GUI's deceptive similarity to a standard download dialog for putting these ideas into people's heads. By all means, KDE needs to support BitTorrent natively, and if nobody goes and implements it anytime soon, then I will. Just don't try to force it into being an HTTP workalike, because all that gets you is a handicapped implementation.
I believe Bittorrent should be implemented as a KIO slave to satisfy the user requirements, as a thin adapter to a persistent daemon in the background that satisfies the protocol requirements. The simplicity of most Bittorrent GUI's reflect what the user requires to utilize the protocol. The complexity of the protocol and the requirements of its persistent state are merely ancillary. Much like we do not see HTTP or FTP or equivalent protocols, Bittorrent should be transparent, I believe. As a user, it is a means of acquiring a file, equivalent to HTTP, FTP, or even TCP/IP. Transparent and useful. The effect of a KIO slave is that it is usable in any number of places. A persistent daemon can manage the complexities of the protocol, as well as providing reporting and reasonable reciprocity to the communal downloads. Obviously there are any number of IPC's they can use, but I would suggest DCOP. This means modifying the existing Bittorrent Python to handle DCOP, and making a thin Bittorrent DCOP wrapper as a KIO slave. It seems simple to me. :)
> The simplicity of most Bittorrent GUI's reflect what the user requires to >utilize the protocol. The complexity of the protocol and the requirements of its >persistent state are merely ancillary. >Much like we do not see HTTP or FTP or equivalent protocols, Bittorrent should be >transparent, I believe. As a user, it is a means of acquiring a file, equivalent >to HTTP, FTP, or even TCP/IP. Transparent and useful. This is a clearer exposition of my thinking when filing this wish in the first place. Thanks. Krishna Sethuraman
We are going to take bittorrent in cosideration while developing KGet2 (work in progress.. we'll keep you informed).
In addition to this, it would be nice if some nice developer could whip up a BitTorrent kio slave. This way we could do a 'torrent:/home/user/file.torrent' and open torrents that way. If the ioslave was in place, I would imagine that integrating that io mechanism into KGet would not be too difficult, and as well we'd have a new torrent protocol to use with Konqueror. Anyone agree?
From comment 10: > Obviously there are any number of IPC's they can use, but I would suggest > DCOP. This means modifying the existing Bittorrent Python to handle DCOP, and > making a thin Bittorrent DCOP wrapper as a KIO slave. It seems simple to me. We probably need a C++ implementation of BitTorrent, because I don't think KDE depends on python now, and we probably don't want to add that dependancy. (Ok, these are just opinions). Also, there should be a way to set the bandwidth limit, view status of downloads, and cancel downloads after they have completed. Preferable way is with a taskbar icon. BitTorrent is actually beginning to replace ordinary file downloads - many distributions and other places are using it as the preferred method of downloading files. Making BitTorrent as easy to use as HTTP will make KDE/Linux a leader in the new age of "distributed downloads".
A C++ implementation library of bittorrent: http://libtorrent.rakshasa.no/ Not sure if it is usable, but it looks like the right stuff.
Theres ctorrent, http://ctorrent.sourceforge.net/
I think the right way to implement this would be a kio slave for bittorrent. It could use kget to transfer files and would be perfectly integrated into kde. Everything else is to complicated and we have bittorrent support (even through the mldonkey ioslave) in kmldonkey now, so this is not absolutely neccessary.
Hi, I just wanted to let you know that I started work on a bittorrent transfer implementation based on http://libtorrent.rakshasa.no/ for kget's make_it_cool branch. The code is not in CVS yet and the kget in the branch is not quite ready to handle the new transfer class. The transfers basically work, but there's still lots of cleanups to be done. I thought I'd let you know to avoid a duplication of efforts. Regards, Felix
Thanks, i would love to see this feature in kde :)
There is a Qt program called qtorrent written in python that does a damn good job. I would agree intergrating bittorent into kget in a recipe for disaster.
nonsense. if bittorrent is implemented as a KIO-slave it will be supported automatically. And why this is bad considering the plethora of already supported protocols is beyond me. kde could be the first O/S to support bittorrent natively which would be great especially for *legal* uses. If people want to download movies they will get a seperate bittorrent client anyway but the average user wont bother to download a seperate bittorrent client to download a new KDE version. This would take a lot of load off the servers. Others seem to agree judging from so far 2770 votes.
> I would agree intergrating bittorent into kget in a recipe for disaster. How is it a recipe for disaster? BitTorrent is the future of downloading files, so Kget and in fact the entire of KDE should get an implementation of it in straight away. The KIO slave could even give info on the tracker and other cool stuff.
>The KIO slave could even give info on the tracker and other cool stuff. Absolutly agree.
with most/all free linux distro's available for download via torrent, native support in kde would make me (and probably everybody) click the torrent link and save the webmasters money on bandwidth. FTP, HTTP, IRC, SMTP, and just about ever protocol which can be used to share files has been used for file sharing, i dont believe bittorrent should be outcast just because its popular for filesharing. A gnutella or fasttrack kioslave would be a different story altogether.
I'd just like to add that (imho) any bittorrent kioslave if ever developed should support upnp for opening of ports (common home routers support it, and i think windowsxp as a nat box does too).
Can you provide me with the specs for the UPnP protocol?
You mean this: http://www.upnp.org/resources/specifications.asp ?
Thanks, I'll add UPnP to my To-Do list.
On Friday 10 June 2005 06:27, Thiago Macieira wrote: > Can you provide me with the specs for the UPnP protocol? http://upnp.sourceforge.net/ Might be of interest too...
I wonder how I can track the development of the kget bittorrent implementation, I've checked the WebSVN - http://websvn.kde.org/trunk/KDE/kdenetwork/kget/ - but I haven't seen any log entry about the work on bittorrent?
On Friday 10 June 2005 18:42, Sander van Loon wrote: > I wonder how I can track the development of the kget bittorrent > implementation, I've checked the WebSVN - > http://websvn.kde.org/trunk/KDE/kdenetwork/kget/ - but I haven't seen any > log entry about the work on bittorrent? If you want to give bittorrent a try, you should download the kget experimental branch that you can find in branches/work/make_kget_cool. In order to have the bittorrent plugin working you should also install a recent libtorrent library from http://libtorrent.rakshasa.no/ And remember that this code is still in a very alpha stage.. Have fun! Dario
Are you working with people from ktorrent to add bittorent support into kget ? ktorrent is simple, works well. From a UI POV, it could easily be integrated into kget. As we have a pdf,ps,dvi etc ...viewer for each of these files and we try to have only only one for them all, it would be a great idea not to have one application for each protocol :)
On Thursday 08 September 2005 09:36, Gael Beaudoin wrote: > Are you working with people from ktorrent to add bittorent support into > kget ? ktorrent is simple, works well. No. Up to now we are using the external library named libtorrent. But nothing prevents us from adding another kget plugin that uses the ktorrent code. And I'll most likely do so, in the future! > As we have a pdf,ps,dvi etc ...viewer for each of these files and we try to > have only only one for them all, it would be a great idea not to have one > application for each protocol :) Yeah! That's exactly what kget2 has been designed for: to be an universal download manager with a powerful plugin architecture. Cheers, Dario Massarin
Glad to hear that :) Thanks for your work!
I humbly thinks that bittorrent is not a friendly protocol to integrate as kioslave or others since a bittorrent download takes a considerable amount of time. For example, consider a 2MB zip file. It could be downloaded from ftp or http within 8sec approximately (on 2048kbps DSL) while it could take let's say 10 minutes depending on trackers available. I don't see the point in this. I think it's better to use a separate application. ktorrent works quite, altough it has some things to improve. Using kget seems nice as well, but in this case I hope it includes up/down bandwith limiting. ;)
I just wanted to point out that a small file will take a small amount of time, and a big file will take a large amount of time to download. This is regardless of which protocol it's downloaded through, whether ftp or bittorrent. As a sidenote, Opera has built-in support for torrents now.
In reply to comment #9, > BitTorrent just isn't a simple download protocol, and needs an > interface more adapted to its particular paradigm. Most correct. Perhaps just like Kontact wraps apps like KMail and Akregator and so on, we can have a KDownload that wraps KGet, the HTTP/FTP downloader and KTorrent, the BitTorrent downloader, with an adaptible interface. I thought of this idea when I found that I have some FTP downloads and some torrents, and am unable to throw them all in a single queue so the bandwidth is used in order by one after another. I add my votes.
While I think eventually a kioslave for torrents should be available, I think it's a lot of work. I'd think integrating ktorrent (and/or kmldonkey, athena etc.) into kget or some other "universal" download application has a better user experience improvement to developer time ratio.
There exists already a kio-slave for kmldonkey. Just try "mldonkey:///" ...
I'm glad about the decision to integrate libtorrent, since most of the other torrent implementations have disastrous memory/performance requirements. Try running 30 torrents at the same time, and you will see... (you can try rtorrent which uses libtorrent for a comparison)
I don't know about the performance of libtorrent, but ktorrent (2.0.2) is happily running over 20 torrents (and completely saturating both up and downstream on my 9Mb/1Mb connection) in 238m of virtual memory, with only 80m resident -- and that's which it's memory usage setting on "High". CPU usage is completely negligible. I'm not arguing against libtorrent, just saying that ktorrent already provides an efficient KDE interface to torrents, and it might be easier to integrate.
The amount of connections is negligable on 1mbit upstream. So, yes, in your case it shouldn't make much of a difference. However I have not tried ktorrent yet, and they may in fact have very similar performance. In my comment, I was comparing to other lib-like implementations, since (at first glance) ktorrent seems to consist more or less of monolithic code (GUI + bittorrent imp.)
I haven't viewed the ktorrent code, but if it is a poor example of separation of responsibilities as you say, I'm sure a lib-based implementation will be easier to integrate and maintain. How is libtorrent-based support coming in the work/make_kget_cool branch? Still alpha and/or will we see it in KDE 4.0? Felix or Dario?
On Thursday 14 September 2006 21:12, Boyd Stephen Smith Jr. wrote: > How is libtorrent-based support coming in the work/make_kget_cool branch? > Still alpha and/or will we see it in KDE 4.0? Felix or Dario? The ktorrent code is really good, and already provides a good decoupling between the gui code and the torrent code. We already asked Joris how to import it in kget and it turned out that from his point of view the best choice was to copy the torrent code inside kget (and thus creating a whole new kget plugin) and keep it up to date with ktorrent. Now, as you know, ktorrent hasn't been ported to KDE4 yet, so I guess he is going to do this work somewhen after this has happened. Speaking about the libtorrent vs ktorrent comparison, ktorrent seems easier to maintain because we will have its author working directly on kget, it would't need any extra library dependency and the code itself is already based on Qt. So, from this point of view, it seems a better solution. I don't know, as of now, how libtorrent and ktorrent differ in performance and memory usage, but even here, I suppose that having Joris from our side could put us in a good position to improve stuff, whenever necessary. Anyway, the libtorrent plugin is there and could be easily further developed, if someone cares. We could even have both of them.. So if someone is interested in improving the libtorrent plugin, your help would be appreciated :) Best regards, Dario
Are you talking about rasterbars libtorrent or rtorrents libtorrent? If it's rasterbars libtorrent maybe you could work together with qBittorrent. qBittorrent uses Qt 4, so maybe it could help to integrate it in KDE.
Just for the record, I'd prefer rakshasa's libtorrent (rtorrent's libtorrent) because, aside from a lack of DHT support, it does everything I want and, with popularity, might come DHT patches. (I'd still use rTorrent because I like to proxy my client through screen or dtach)
I move for this bug to be closed, because KTorrent seems to have become KDE's DeFacto Bittorrent client. Perhaps we should simply add an option to KGet to pass KTorrent the download location etc. when it downloads a .torrent file?
Actually, I would like something like that, but only if it can be set to drop the torrent file into a configurable folder. (That would make it compatible with rTorrent's watchdir feature) On 10 Aug 2007 23:03:35 -0000, Alex Lowe - lengau@gmail.com <+kde_bugzilla+ssokolow+4b62e5251e.lengau#gmail.com@spamgourmet.com> wrote: [bugs.kde.org quoted mail]
Oops. Well, could have been worse for my first time doing an e-mail reply.
We will not close this wish. Our plans are to implement a torrent plugin, based on KTorrent, in KGet. This way a user is able to download torrents with a KDE standard setup (without extragear apps).
Ok, bittorrent-plugin based on libktorrent is now in work for 4.1 :-) Cheers Lukas
Hi! We have enabled the torrent-plugin, based on libbtcore (former libktorrent) enabled per default in trunk. This will be released with KDE 4.1 ... Lukas