[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: (no subject)
From:       "Petter E. Stokke" <gibreel () project23 ! no>
Date:       2004-01-10 20:30:59
Message-ID: 200401102131.04980.gibreel () project23 ! no
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 10 January 2004 00:35, Jason Keirstead wrote:
> On January 09, 2004 07:03 pm, Helio Chissini de Castro wrote:
> > False ? all donkey links works ok, maybe missing same for torrent
> > links, but again, i use kmldonkey very well with both donkey and
> > torrent files
>
> So? The links work, so what? I can click on an MP3 link and have it open
> in XMMS, it doesn't mean that XMMS is using KIO or that it is integrated
> with KDE.
>
> A bittorrent IO Slave could use the KIO progress dialogs and
> everything... the user wouldn't even have to *know* what a torrent was.

The issue of a BitTorrent KIO slave has been discussed in the past too, and 
I still maintain it's a startlingly bad idea, although it seems like a 
great thing to have on the surface. The BitTorrent protocol doesn't mesh 
well with the KIO paradigm - it's not anything close to a streaming 
protocol, and you can't refer to a BitTorrent download with a URL, only to 
the torrent file which initiates it. Besides, the whole BitTorrent concept 
hinges on the downloading clients keeping the torrent running well past 
download completion. Trying to manage all this with KIO would amount to 
nothing more than a nasty hack - what's needed is a BitTorrent download 
manager along the lines of Azureus (http://azureus.sourceforge.net/), not 
trying to make your favourite KDE infrastructure do something it's not 
meant to be doing.

Also, KMLDonkey as a BitTorrent client is kind of defeated by the fact that 
mldonkey's BT support is nothing short of abysmal. This is the primary 
reason why KMLDonkey doesn't handle torrent links out of the box.

I'd definitely like to see BitTorrent implemented for KDE, and, like Mr. 
Pyne, I also tried my hand at getting a BT client going once, and didn't 
get much farther than the BEncoding, although, unlike Mr. Pyne, my efforts 
didn't result in any useful product. I'm coming to believe that the best 
way to go would be to simply use the original BitTorrent code along with 
some Python DCOP glue to produce a kded-like service, w9th a GUI frontend 
to go with it; a bit like the mldonkey/KMLDonkey combination, only more 
specifically tailored to the particular needs of the BitTorrent protocol. 
It has the great advantage of being easier to implement, not to mention 
more compatible, than any C++ reimplementation. I doubt the Python 
dependency would constitute an added burden to any KDE user these days.

-- 
Petter E. Stokke <gibreel@project23.no> http://www.gibreel.net/
PGP key: http://www.gibreel.net/key.asc
Fingerprint: 4FF3 12BD 692A 0FFF 984F  78DA 4776 81FB 1906 3A9F

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]