bittorrent in core? what frontend?

Luke Macken lmacken at
Thu Dec 15 20:02:05 UTC 2005

On Thu, Dec 15, 2005 at 02:11:43PM -0500, Jeff Spaleta wrote:
| On 12/15/05, Michael Favia <michael.favia at> wrote:
| > Jeff Spaleta wrote:
| > While i agree with j5 statemnt on simplicity i disagree that closing the
| > torrent "defeats" the purpose. Even if individuals close the torrent
| > after download they still supported the torrent throughout their
| > download.
| I have no problem letting users choose to stop their local bittorrent
| node whenever they wish. 

I think this is absolutely necessary.  Bittorrent has the power to
saturate a network real quick, and the last thing we want is a client
that could potentially sit in the background behind peoples back
un-noticed eating bandwidth just because we think keeping a 1:1 ratio
is The Right Thing.

This is where a slick notification applet would come in handy.

| What I have a problem with is a default
| application that shutdowns the node activity at the end of downloads
| by default for everyone... pretending to be something like an http or
| ftp download client.  The peer activity of the bittorrent process is
| important and i think it needs to be clear in the UI that uploads are
| happening and can continue to happen as long as the local bittorrent
| client stays alive.

The default gui client has sane post-completion seeding settings, so it
doesn't end the seed when the download is finished.

| I think its a bastardization of the bittorrent concept to have the
| default client in Core that people will reach for be so simple as to
| shutdown upload activity at the  end of download activity without
| making an effort to educate the user that bittorent is a peer process
| and gives the user the choice to turn off the upload activity or leave
| it running.  A notification area icon which uses the libnotify bubbly
| crap seems most appropriate to me.

I agree.


More information about the devel mailing list