Re: Offering help

[thi]

   From: Martin Grabmueller <address@hidden>
   Date: Thu, 04 Jan 2001 12:19:55 +0100

   Excuse my ignorance: But what is freenet? An IRC network?

it's a peer-to-peer distributed (and encrypted and anonymized) content
network.  check out http://freenet.sourceforge.net

after more browsing, i'm thinking freenet might be overkill, but hoping
someone who has played w/ the released client can give some insight.

   Hm, the list is very vague, maybe you can explain:

yes, it's very rough.  thanks for the good questions, these help me to
focus my thoughts (and even write them down, egad!).  in the following,
"protocol" is used as in Sonya E. Keene's _Object Oriented Programming
In Common Lisp_, which i'm digesting bit by bit, in the sense of the set
of (generic) functions and their documentation that define an interface.

   - define channel protocol and two channels: freenet and degenerate

   What do you mean by `degenerate'?

the degenerate channel follows the protocol but does nothing useful.  on
second thought, if the protocol has hooks (say, for validation), you can
think of the degenerate channel as akin to the unix loopback device.
maybe we should just call it the loopback channel.

   - implement test harness

   What is to be tested?  Communication?  Classification of modules?

communication, classification, mis-classification, valid input, invalid
input, dependency and other code analysis, database corruption, etc.  in
addition to testing gumm itself, the testing code should (and will, by
protocol) be applied to incoming contributions.  stats collected from
testing should be saved in a database.

   - implement channels (can re-use test harness for clients)

   What is to be done for that part?

i'm sure there will be code to write, but the details are still fuzzy.
however, here are my thoughts:

if you wish to get started coding, i would suggest focusing on the test
harness (reflection) part of the project since much of gumm really
depends on that aspect.  more precisely, check out the hobbit compiler
and see if you can pull out into a "(gumm analysis)" module procedures
that read and analyze guile scheme code.  the kind of information we're
most interested in is (exported) module interface (including procedure
signatures) and dependency information.  for the latter, perhaps we can
call out to systems already implemented for the debian project.  feel
free to do other analysis (how about "can this code be compiled by
hobbit into a .so file?" and beyond -- go wild!).

i'm hoping that parts of (gumm analysis) can be contributed to the
(ice-9 reflection) module hinted at in earlier discussion, after use and
subsequent refinement.

thi