Re: [Libbt-devel] what's the typical use-case? [was: mess]

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

Op vrijdag 11 februari 2005 02:03, schreef Peter Stuge:
> On Thu, Feb 10, 2005 at 11:07:33AM -0800, Tyler MacDonald wrote:
> > > - functions for creating torrent files
> > > - functions for checking torrent files
> > > - functions for adding torrent files
> > > - functions for deleting torrent files
> > > - functions for selecting files in torrent files
> > > - functions for initiating the library
> > > - functions for freeing the library
> > > - functions for setting options in the library
> > > - functions for hooking callback functions (or select stuff)
>
> [..]
>
> > - functions for converting peer communication into data structures

i'd rather not, and instead supply a function that gives a the structure=20
that's already in memory

> > - functions for converting peer responses from data structures into
> > buffers * both communication of metadata and actual torrnent data

i don't think this is necessary

> > - functions for enumerating the list of peers we are presently connected
> > to with a callback
> >   * presumedly this function would be part of the core loop
> >   * with write access, to set throttling flag, etc

yes

> > - functions for enumerating the list of available peers with a callback

yes, but it doesn't have to have a callback

> > - functions for dropping connections to specific peers

yes

> > - functions for initiating connections to specific peers

I'm not sure about this one

furthermore, it may be better to have a function that lists ALL torrents bu=
sy=20
and a function that gives all peers/torrent, and functions for adding=20
deleting peers/torrent etc...

wouldn't it be better if the library handled the torrent details, so that=20
frontends were easier to make?

> What are people's intentions for libbt?
>
> I believe it was originally targeted at non-p2p applications, but
> rather as a transport plugin to allow applications to access random
> files via BT.
>
> Should it stay there?
>
> I re-read the protocol spec and since it's really simple it may not
> be worth the effort to work on a library abstracting BitTorrent but
> still allowing fine-grained control over things like outgoing
> bandwidth, which peers should be used/accepted for what, and so on -
> since these things are so easily determined in the actual application
> context anyway.
>
> Thoughts?

probably make them easy by delivering functions for them
=2D-=20
Alien is my name and head-biting is my game.