From kde-devel  Sat Jan 10 20:30:59 2004
From: "Petter E. Stokke" <gibreel () project23 ! no>
Date: Sat, 10 Jan 2004 20:30:59 +0000
To: kde-devel
Subject: Re: (no subject)
Message-Id: <200401102131.04980.gibreel () project23 ! no>
X-MARC-Message: https://marc.info/?l=kde-devel&m=107376738719596
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============0402110377=="


--===============0402110377==
Content-Type: multipart/signed; protocol="application/pgp-signature";
	micalg=pgp-sha1; boundary="Boundary-02=_IEGAA63w/bTx35a";
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


--Boundary-02=_IEGAA63w/bTx35a
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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

Also, KMLDonkey as a BitTorrent client is kind of defeated by the fact that=
=20
mldonkey's BT support is nothing short of abysmal. This is the primary=20
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.=20
Pyne, I also tried my hand at getting a BT client going once, and didn't=20
get much farther than the BEncoding, although, unlike Mr. Pyne, my efforts=
=20
didn't result in any useful product. I'm coming to believe that the best=20
way to go would be to simply use the original BitTorrent code along with=20
some Python DCOP glue to produce a kded-like service, w9th a GUI frontend=20
to go with it; a bit like the mldonkey/KMLDonkey combination, only more=20
specifically tailored to the particular needs of the BitTorrent protocol.=20
It has the great advantage of being easier to implement, not to mention=20
more compatible, than any C++ reimplementation. I doubt the Python=20
dependency would constitute an added burden to any KDE user these days.

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

--Boundary-02=_IEGAA63w/bTx35a
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBAAGEIR3aB+xkGOp8RAilgAKCawwMKdpWcBGMakiWU7blIvCf31QCg110c
Y/0eErIJAKALCKqCF5Jn250=
=DE46
-----END PGP SIGNATURE-----

--Boundary-02=_IEGAA63w/bTx35a--

--===============0402110377==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0402110377==--