Re: [Libbt-devel] Re: Features request

[Alien <ali...@us...>]

Op woensdag 25 mei 2005 14:43, schreef Peter Stuge:
> On Wed, May 25, 2005 at 02:12:42PM +0200, Alien wrote:
> > > But I don't think libbt should go about creating lots of data
> > > bases on it's own, I instead suggest that libbt hands the
> > > information up to the calling application, which can then save it
> > > any way it likes to.
> >
> > the status of everything is available to the calling application,
> > it can deduce stuff from itself, i don't think piecemanagement is a
> > good idea, from the progress, it can see if some files are
> > completely done, so...
>
> Well, that depends on the design goal of libbt, I guess.
>
> Either simple to use for applications that want to add BT support.
> Or feature-complete and means for micro management.
>
> Or perhaps we can have both? I think curl is a good example of both,
> although I do admit I've only used it a few times.

I wanna have both

curl has some shortcomings...

> > > Also, on initializing a torrent with libbt, an optional map of
> > > good pieces could be sent by the application, and libbt would
> > > then assume marked pieces are actually correct.
> >
> > i don't really believe in this... applications shouldn't have
> > anything to do,
>
> Unless it's sole purpose is to do BT and do it extremely well.

it doesn't matter, they should not fiddle with the background of libbt;

libbt sole purpose is to do only libbt and do it well, not the application,=
=20
it's goal is to make calls and display progress, and manage more or less=20
torrents or whatever...

> > and we cannot assume pieces, uploads could go wrong and stuff.
>
> Yes, but then peers will hate you and stop talking to you, which
> makes the problem a non-issue. This should of course be a user
> decision with a sensible default. (Ie. no correct pieces.)

with lost networking, and other people being angry that there are clients o=
ut=20
there that allow broken pieces to be uploaded... no, this is not going to=20
happen, strictly for security reasons and networking reasons only... you wa=
nt=20
fast downloads? you check the pieces.

> > at start, the reading of the file isn't really that slow, and won't
> > interfere with down/uploading or system performance anyway...
>
> It sure interferes with the performance of my system, but otoh I'm on
> a P3 laptop with a 5k4 RPM disk. :)

we'll make it a seperate thread and let you nice it to your likings, ok?

> > I'd advise against these things...
>
> They all need good default values and settings, but ultimately I
> don't think libbt should devise a method to save state between
> invocations. The calling application will probably already have some
> way to save state, I'm guessing different ones for each application,
> and I think it makes more sense to store libbt state at the same
> place, since it's certainly only relevant information within the
> scope of the application.

i don't think that has anything to do with it... if you don't want it to ru=
n=20
and you want it to run later with the same settings, just pause the damn=20
thing... problem solved...

AL13N