libbt-devel

[Libbt-devel] Intro and... suggestions

[Pandora <pub...@pa...>]

Good morning all, Pandora here, aka synx13 on sourceforge.  I like the
notion of a bittorrent library, since I'm planning an app that uses both
bittorrent, and other stuff (some sort of feed protocol).  Since I'd
therefore be making a bittorrent library anyway, I was hoping to help
you folks out with whatever my twisted little mind could cook up.

Okay, intros aside.  I had some difficulty with the CVS of the code.  To
be honest it's gotten quite... messy.  I'd like to discuss some
standards here.  As I fix the code there are a few things I'm not
certain on; things that could go either way.  I have recommendations,
but before acting on those recommendations I'd like to ask other people
here what they'd want.

1) Object naming
Many places (but not all; messy!) I see classes named this way:
| struct btClass;
| typedef struct btClass btClass;
As elegant as that is, my syntax highlighter likes to see _t at the end
of typenames.  It's got a point too: everywhere in C you have to
identify what a type is (struct, union, enum, etc) right by the type
name, except typedefs.  So adding a _t makes it easier to identify
something as a type, and also leaves the class's formal name open for
the name of a variable.

Also, there's a trick we could use so we can even pretend we're not
using pointers, which results in much less * writing, and really seems
to work out elegantly when I've done it.

So I propose we do this:
| typedef struct btClass *btClass_t;
instead of this:
| struct btClass;
| typedef struct btClass btClass;

When we want to get at the implementation of btClass, we can use 'struct
btClass' but otherwise we can toss around btClass_t things like they
were opaque candy.

| btClass  *someFunction(btClass *, btClass **); //The old interface
| btClass_t someFunction(btClass_t, btClass_t*); //The new interface

So... what about that?  Obey my syntax highlighter and use _t?  Typedefs
to all opaque structures as pointers, not just aliases?  I'm going
forward with this system unless anybody brings forth any issues.  Okay?

Re: [Libbt-devel] Intro and... suggestions

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

Hi,

I'm the only one active at this time, and I'm already doing what you descri=
be,=20
except i didn't commit yet, because it'll break CVS HEAD.

but because you seem interested, i'll commit everything now anyway, the min=
ute=20
i get my own version working a little again.

I can tell you that i have gotten far and I restructured everything into a=
=20
functional system, more or less...

this "library" wasn't really a library when I started, they have 3 tools (a=
s=20
the release from the 1.03 branch shows) btcheck, btlist & btget...

the first 2 work more or less, the third is still not operational, because =
i'm=20
working on the peer protocols now.


The things i keep in mind:
 - get rid of libevent
 - think of generalisation: 64bit, IPv6, torrent protocol deviations
 - make headers structured and make internal dependencies
 - see libbt/include/bt/bt.h (it holds a header file that is supposed to ha=
ve=20
all functions).
 - clean up the code

I'll clean up my own version and commit, you'll see what i mean, then...

Secondly, i've been trying to get in touch with project admin of this proje=
ct,=20
and now you've suddenly became one... odd, but what the hell

there's a guy that wanted to help (like a month back) and he asked ext CVS=
=20
access, but he never got a reply...=20

please set trove categorisation, that's been buggin me, since i got here...

I'm here because i wanted a library i could use for my own application...

oh yeah: can you read the archives of the mailing list for a month or two=20
back?

AL13N

Op woensdag 20 april 2005 07:16, schreef Pandora:
> Good morning all, Pandora here, aka synx13 on sourceforge.  I like the
> notion of a bittorrent library, since I'm planning an app that uses both
> bittorrent, and other stuff (some sort of feed protocol).  Since I'd
> therefore be making a bittorrent library anyway, I was hoping to help
> you folks out with whatever my twisted little mind could cook up.
>
> Okay, intros aside.  I had some difficulty with the CVS of the code.  To
> be honest it's gotten quite... messy.  I'd like to discuss some
> standards here.  As I fix the code there are a few things I'm not
> certain on; things that could go either way.  I have recommendations,
> but before acting on those recommendations I'd like to ask other people
> here what they'd want.
>
> 1) Object naming
>
> Many places (but not all; messy!) I see classes named this way:
> | struct btClass;
> | typedef struct btClass btClass;
>
> As elegant as that is, my syntax highlighter likes to see _t at the end
> of typenames.  It's got a point too: everywhere in C you have to
> identify what a type is (struct, union, enum, etc) right by the type
> name, except typedefs.  So adding a _t makes it easier to identify
> something as a type, and also leaves the class's formal name open for
> the name of a variable.
>
> Also, there's a trick we could use so we can even pretend we're not
> using pointers, which results in much less * writing, and really seems
> to work out elegantly when I've done it.
>
> So I propose we do this:
> | typedef struct btClass *btClass_t;
>
> instead of this:
> | struct btClass;
> | typedef struct btClass btClass;
>
> When we want to get at the implementation of btClass, we can use 'struct
> btClass' but otherwise we can toss around btClass_t things like they
> were opaque candy.
>
> | btClass  *someFunction(btClass *, btClass **); //The old interface
> | btClass_t someFunction(btClass_t, btClass_t*); //The new interface
>
> So... what about that?  Obey my syntax highlighter and use _t?  Typedefs
> to all opaque structures as pointers, not just aliases?  I'm going
> forward with this system unless anybody brings forth any issues.  Okay?
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime
> info, new features, or free trial, at:
> http://www.businessobjects.com/devxi/728
> _______________________________________________
> Libbt-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libbt-devel

Re: [Libbt-devel] Intro and... suggestions

[Dakidd <da...@so...>]

>Hi,
>
>I'm the only one active at this time, and I'm already doing what you
>describe,
>except i didn't commit yet, because it'll break CVS HEAD.

Hi yerself! :)

No, Alien, you're not the "only one active"... I've just been effectively
silent, quietly banging away at adding stuff to make the thing truly
cross-platform. As it stands now, it's Windows/*nix freindly (at least for
the most part) but actively hostile to those of us still stuck by
circumstances working on Macs that run an OS version below MacOS X (MacOS X
folks can use it *ALMOST* "as-is" due the the unix-like underpinnings of
the OS). I'm hacking away, slowly but steadily, at changing that with a
massive introduction of
#if TARGET_MACOS
...
#else
...
#endif
conditionals. At this point, I've done SOMETHING that has broken most of
the library in a massive way, and am working on figuring out what it was
that turned out to be "poison", but prior to the change that did it,
btcheck, and "ctx_loadfile", which was basically all it called directly,
was working 100% for me. I'll try to keep the list posted as I make
progress back to functionality.

FWIW:
I started my "battle" on version 0.3, and that's where I'm sticking at
least until I get things back to functional. It appears as though 1.3 is
*MOSTLY* very similar, at least in the "core" btxxxxx code but I haven't
wrapped my head around the various changes that come with the most recent
versions, so I'm a lot more comfortable dealing with "the old one" until I
get it functional again.

If you'd like to see my changes so far, I'm willing to crate up SOME
sections and pass them along to anyone interested, but outside of the
"core" code listed, it's pretty much a minefield, since I've had to hack
out huge swathes of utterly incompatible networking code to get a compile
at all - peer.c being particularly obnoxious for me at this point - I'd
estimate I've got more than 75% of it commented or conditionalized onto the
scrapheap - It's THAT hostile to Mac-style networking.

Such a "crate up and send" will, by neccessity, have to be done "outside
the channel" of CVS, since, quite bluntly, I'm *NOT* going to take the time
needed to re-acquire the programs and skills needed to work with CVS away
from banging on the code - never mind that committing anything in the shape
it's currently in on my machine would be something close to a terrorist
attack in terms of likely "damage" to the current codebase.

>but because you seem interested, i'll commit everything now anyway, the
>minute
>i get my own version working a little again.
>
>I can tell you that i have gotten far and I restructured everything into a
>functional system, more or less...
>
>this "library" wasn't really a library when I started, they have 3 tools (as
>the release from the 1.03 branch shows) btcheck, btlist & btget...
>
>the first 2 work more or less, the third is still not operational, because
>i'm
>working on the peer protocols now.



>The things i keep in mind:
> - get rid of libevent

Doesn't exist in MY copy of the source, but then, as mentioned, I'm working
from an old (v0.3) sourcebase.

> - think of generalisation: 64bit, IPv6, torrent protocol deviations

Something that should be "back burner" at least until basic IPv4/32 bit
functionality is achieved - IMO...

> - make headers structured and make internal dependencies




> - see libbt/include/bt/bt.h (it holds a header file that is supposed to have
>all functions).

This item is a *HUGE* one in my book, and in my opinion, needs to be at the
top of the priority list.

> - clean up the code

Not far behind creation of a useful bt.h file in priority. Again, my opinion...


Don Bruder -  da...@so...      <--- Preferred Email - unmunged
I will choose a path that's clear: I will choose Free Will! - N. Peart

[Libbt-devel] Coordinating development

[Emil S. <si...@MI...>]

On Wed, 20 April 2005 at 17:48 (-0700), Dakidd wrote:
> No, Alien, you're not the "only one active"... I've just been effectively
> silent, quietly banging away at adding stuff to make the thing truly

I don't have the time to contribute to libbt unfortunately.
However, I am worried that there are currently many developers
proceeding on essentially independent paths with very little
coordination.

This could be improved probably in several ways ---

  * Updating the libbt website on sf to indicate the current
    status and future plans, perhaps adding a registration-required
    wiki.
  * Automatic e-mails after commits to CVS.
  * Hanging out on the IRC channel (#libbt on irc.freenode.net)
  * Having someone actually be in charge: Kevin, could you clarify
    what role you want to play in libbt?

In addition to these logistic items (which don't require any one to
write any code), it might be nice if there were some sort of
consensus on these items before people continue hacking:

  * Release goals/plan
  * API definition
    - Model for integration with applications (separate process or
      linked in library with appropriate I/O multiplexing)
  * Implementation decisions:
    - code style
    - portable string/binary library
    - portable network I/O

Re: [Libbt-devel] Intro and... suggestions

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

Op donderdag 21 april 2005 02:48, schreef Dakidd:
> >Hi,
> >
> >I'm the only one active at this time, and I'm already doing what you
> >describe,
> >except i didn't commit yet, because it'll break CVS HEAD.
>
> Hi yerself! :)
>
> No, Alien, you're not the "only one active"...=20

sorry, but I haven't heard much from you... and I am the only one active at=
=20
CVS, no offense.

> I've just been effectively=20
> silent, quietly banging away at adding stuff to make the thing truly
> cross-platform. As it stands now, it's Windows/*nix freindly (at least for
> the most part) but actively hostile to those of us still stuck by
> circumstances working on Macs that run an OS version below MacOS X (MacOS=
 X
> folks can use it *ALMOST* "as-is" due the the unix-like underpinnings of
> the OS). I'm hacking away, slowly but steadily, at changing that with a
> massive introduction of
> #if TARGET_MACOS
> ...
> #else
> ...
> #endif
> conditionals. At this point, I've done SOMETHING that has broken most of
> the library in a massive way, and am working on figuring out what it was
> that turned out to be "poison", but prior to the change that did it,
> btcheck, and "ctx_loadfile", which was basically all it called directly,
> was working 100% for me. I'll try to keep the list posted as I make
> progress back to functionality.

portability is good, i guess...

> FWIW:
> I started my "battle" on version 0.3, and that's where I'm sticking at
> least until I get things back to functional. It appears as though 1.3 is
> *MOSTLY* very similar, at least in the "core" btxxxxx code but I haven't
> wrapped my head around the various changes that come with the most recent
> versions, so I'm a lot more comfortable dealing with "the old one" until I
> get it functional again.
>
> If you'd like to see my changes so far, I'm willing to crate up SOME
> sections and pass them along to anyone interested, but outside of the
> "core" code listed, it's pretty much a minefield, since I've had to hack
> out huge swathes of utterly incompatible networking code to get a compile
> at all - peer.c being particularly obnoxious for me at this point - I'd
> estimate I've got more than 75% of it commented or conditionalized onto t=
he
> scrapheap - It's THAT hostile to Mac-style networking.

just a note, on CVS HEAD: peer.c is being completely rewritten. I do howeve=
r=20
not check anything little or big endian. which is not portable for some=20
*nixes including mac. but I must admit that there isn't much htonl stuff=20
anymore.

> Such a "crate up and send" will, by neccessity, have to be done "outside
> the channel" of CVS, since, quite bluntly, I'm *NOT* going to take the ti=
me
> needed to re-acquire the programs and skills needed to work with CVS away
> from banging on the code - never mind that committing anything in the sha=
pe
> it's currently in on my machine would be something close to a terrorist
> attack in terms of likely "damage" to the current codebase.

since I'm getting like "back to basics", for efficiency and maybe a little=
=20
portability reasons, you might be interested to check out how CVS HEAD work=
s=20
and extract it in a second codebase.

> >but because you seem interested, i'll commit everything now anyway, the
> >minute
> >i get my own version working a little again.
> >
> >I can tell you that i have gotten far and I restructured everything into=
 a
> >functional system, more or less...
> >
> >this "library" wasn't really a library when I started, they have 3 tools
> > (as the release from the 1.03 branch shows) btcheck, btlist & btget...
> >
> >the first 2 work more or less, the third is still not operational, becau=
se
> >i'm
> >working on the peer protocols now.
> >
> >
> >
> >The things i keep in mind:
> > - get rid of libevent
>
> Doesn't exist in MY copy of the source, but then, as mentioned, I'm worki=
ng
> from an old (v0.3) sourcebase.

thank god

> > - think of generalisation: 64bit, IPv6, torrent protocol deviations
>
> Something that should be "back burner" at least until basic IPv4/32 bit
> functionality is achieved - IMO...

well, I'm on a 64bit CPU and OS, so, it's big for me, i've never had it=20
working...

!plus! I am programming protocol independant, this reduces alot of htonl ca=
lls=20
and is much more simpler.

> > - make headers structured and make internal dependencies
> >
> >
> >
> >
> > - see libbt/include/bt/bt.h (it holds a header file that is supposed to
> > have all functions).
>
> This item is a *HUGE* one in my book, and in my opinion, needs to be at t=
he
> top of the priority list.

most of this is done.

> > - clean up the code
>
> Not far behind creation of a useful bt.h file in priority. Again, my
> opinion...

I must tell you that all of these above are only my big priorities...

good luck, and maybe you should check out CVS, or check the very near new=20
release for mac compatibility.

Re: [Libbt-devel] Coordinating development

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

Op donderdag 21 april 2005 03:39, schreef Emil Sit:
> On Wed, 20 April 2005 at 17:48 (-0700), Dakidd wrote:
> > No, Alien, you're not the "only one active"... I've just been effective=
ly
> > silent, quietly banging away at adding stuff to make the thing truly
>
> I don't have the time to contribute to libbt unfortunately.
> However, I am worried that there are currently many developers
> proceeding on essentially independent paths with very little
> coordination.

This is a little where you're wrong: kevin said he was only busy with 1.03=
=20
branch, and that noone else was busy with CVS. and at the time, he was righ=
t.=20

In the time i just got here, I've been the only one changing CVS. ( and i=20
don't touch the stable branch ).

and since I'm the one doing the heavy coding, I expect my say to carry=20
somewhat far.

> This could be improved probably in several ways ---
>
>   * Updating the libbt website on sf to indicate the current
>     status and future plans, perhaps adding a registration-required
>     wiki.

can't help you there

>   * Automatic e-mails after commits to CVS.

don't think it's necessary

>   * Hanging out on the IRC channel (#libbt on irc.freenode.net)

i'm already there ;-)

>   * Having someone actually be in charge: Kevin, could you clarify
>     what role you want to play in libbt?

yes, actually in charge, this is the major problem I have been having, i=20
cannot seem to contact kevin...

> In addition to these logistic items (which don't require any one to
> write any code), it might be nice if there were some sort of
> consensus on these items before people continue hacking:
>
>   * Release goals/plan
>   * API definition
>     - Model for integration with applications (separate process or
>       linked in library with appropriate I/O multiplexing)

more or less finished ( libbt/include/bt/bt.h ) + see also libbt/TODO

>   * Implementation decisions:
>     - code style
>     - portable string/binary library
>     - portable network I/O

can be usefull to agree upon.

The big problem is that there is no active maintainer, therefor I repectful=
ly=20
ask of kevin or Pandora that I be given maintainer priviledges. I will not=
=20
act without consulting the mailing list, but I can be there _every_ day to=
=20
"maintain" libbt.

I have a buddy who wanted to help me coding on libbt HEAD CVS, and he still=
=20
(more or less a month) waits for ext CVS access or for kevin to contact him=
=2E=20
I just hope he wants to help now...


As a side note, I have mostly rewrote the existing code (at least i copy pa=
ste=20
some stuff, and some stuff I leave; but there isn't a file that's been=20
changed; and some are now obsolete ).

Re: [96] [Libbt-devel] Coordinating development

[Kevin S. <ke...@an...>]

>>  * Hanging out on the IRC channel (#libbt on irc.freenode.net)
>>    
>>
>
>i'm already there ;-)
>
>  
>
I'm not on IRC, but I can be IM'd at any of:

Y!: kevin_at_ank AT yahoo DOT com
MSN: kevin.smathers AT hp DOT com
ICQ:  56409049

>>  * Having someone actually be in charge: Kevin, could you clarify
>>    what role you want to play in libbt?
>>    
>>
>
>yes, actually in charge, this is the major problem I have been having, i 
>cannot seem to contact kevin...
>  
>
LibBT is one of several spare time research projects of mine.  I do work 
on it when I happen to need to transfer something through BitTorrent and 
find that it has broken with respect to current client customs.  At 
present my real research project at the lab is taking most of my 
attention (I was up at 4am for telecon's all this week for example), and 
what spare time I have I've been working on a different, though 
complementary program.  When that development is at a stage where I will 
need BT again, I'll take the time to either retread LibBT or else 
rewrite based on whatever the current protocol spec is (if Bram ever 
gets his Merkle tree specification finished.)

If LibBT main branch manages to track the protocol (through people like 
Vanraes who have the time to make it do so), and simultaneously define 
some sort of library API, then great, I might not have to do any work 
when I need LibBT again later.

I see the main trunk as a playground -- there should be room for 
experimentation there.  If the experiment fails, I'll revert the trunk 
and start over, or else let whoever wants to play on the trunk next do 
so.  If the experiment succeeds in being more useful than the stable 
branch (with all of its limitations) then I have no problem with letting 
it evolve.

>  
>
>>In addition to these logistic items (which don't require any one to
>>write any code), it might be nice if there were some sort of
>>consensus on these items before people continue hacking:
>>
>>  * Release goals/plan
>>  * API definition
>>    - Model for integration with applications (separate process or
>>      linked in library with appropriate I/O multiplexing)
>>    
>>
>
>more or less finished ( libbt/include/bt/bt.h ) + see also libbt/TODO
>
>  
>
>>  * Implementation decisions:
>>    - code style
>>    - portable string/binary library
>>    - portable network I/O
>>    
>>
>
>can be usefull to agree upon.
>
>The big problem is that there is no active maintainer, therefor I repectfully 
>ask of kevin or Pandora that I be given maintainer priviledges. I will not 
>act without consulting the mailing list, but I can be there _every_ day to 
>"maintain" libbt.
>
>I have a buddy who wanted to help me coding on libbt HEAD CVS, and he still 
>(more or less a month) waits for ext CVS access or for kevin to contact him. 
>I just hope he wants to help now...
>
>  
>
No offense but I didn't see anything in his email that made me want to 
grant him developer access.   Have the
guy submit patches until he shows an interest in some development project. 

>As a side note, I have mostly rewrote the existing code (at least i copy paste 
>some stuff, and some stuff I leave; but there isn't a file that's been 
>changed; and some are now obsolete ).
>  
>

Re: [96] [Libbt-devel] Coordinating development

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

Op zaterdag 23 april 2005 06:33, schreef Kevin Smathers:
> >>  * Hanging out on the IRC channel (#libbt on irc.freenode.net)
> >
> >i'm already there ;-)
>
> I'm not on IRC, but I can be IM'd at any of:
>
> Y!: kevin_at_ank AT yahoo DOT com
> MSN: kevin.smathers AT hp DOT com
> ICQ:  56409049
>
> >>  * Having someone actually be in charge: Kevin, could you clarify
> >>    what role you want to play in libbt?
> >
> >yes, actually in charge, this is the major problem I have been having, i
> >cannot seem to contact kevin...
>
> LibBT is one of several spare time research projects of mine.  I do work
> on it when I happen to need to transfer something through BitTorrent and
> find that it has broken with respect to current client customs.  At
> present my real research project at the lab is taking most of my
> attention (I was up at 4am for telecon's all this week for example), and
> what spare time I have I've been working on a different, though
> complementary program.  When that development is at a stage where I will
> need BT again, I'll take the time to either retread LibBT or else
> rewrite based on whatever the current protocol spec is (if Bram ever
> gets his Merkle tree specification finished.)
>
> If LibBT main branch manages to track the protocol (through people like
> Vanraes who have the time to make it do so), and simultaneously define
> some sort of library API, then great, I might not have to do any work
> when I need LibBT again later.
>
> I see the main trunk as a playground -- there should be room for
> experimentation there.  If the experiment fails, I'll revert the trunk
> and start over, or else let whoever wants to play on the trunk next do
> so.  If the experiment succeeds in being more useful than the stable
> branch (with all of its limitations) then I have no problem with letting
> it evolve.

I think it's well on it's way to become more usefull, but it isn't now... I=
=20
may well like to make a pre-release within a few weeks, maybe a month

> >>In addition to these logistic items (which don't require any one to
> >>write any code), it might be nice if there were some sort of
> >>consensus on these items before people continue hacking:
> >>
> >>  * Release goals/plan
> >>  * API definition
> >>    - Model for integration with applications (separate process or
> >>      linked in library with appropriate I/O multiplexing)
> >
> >more or less finished ( libbt/include/bt/bt.h ) + see also libbt/TODO
> >
> >>  * Implementation decisions:
> >>    - code style
> >>    - portable string/binary library
> >>    - portable network I/O
> >
> >can be usefull to agree upon.
> >
> >The big problem is that there is no active maintainer, therefor I
> > repectfully ask of kevin or Pandora that I be given maintainer
> > priviledges. I will not act without consulting the mailing list, but I
> > can be there _every_ day to "maintain" libbt.
> >
> >I have a buddy who wanted to help me coding on libbt HEAD CVS, and he
> > still (more or less a month) waits for ext CVS access or for kevin to
> > contact him. I just hope he wants to help now...
>
> No offense but I didn't see anything in his email that made me want to
> grant him developer access.   Have the
> guy submit patches until he shows an interest in some development project.

ok, no problem

but the real problem is that you aren't in contact when I need to contact y=
ou,=20
don't you check your mails? or didn't my mails come through?

as a second thing, how about maintainer priviledges, so I can change trove=
=20
categorisation, and change tracker stuff and etc... and file releases when =
i=20
have to.