Re: GUMM

[thi]

   From: Evan Prodromou <address@hidden>
   Date: 02 Apr 2001 02:06:20 -0700

   Hey, wow, I so want to work on this! I just spent several days making
   it possible to use Freenet from Guile, so I'm PSYCHED to see this as
   part of the plan. Not to mention all the XML hoohaw, too... Although
   I'd expect GUMM would be defined in terms of sexps rather than
   XML. Anyways, this is rokken like dokken, and I want to talk to
   interested people about making it happen.

cool.  i'm glad to find motivated people who are interested in
developing GUMM.  if you are interested in working in the policy side of
things, see next paragraph:

to avoid excessive (heh) backtracking, check out the various module
hierarchy proposals made over the years.  a good place to start would be
Martin Grabmueller's writeup, which should be available in cvs guile in
devel/modules.  older discussion can be found by feeding "module
hierarchy" into the cygnus guile mailing list search engine, i believe.
in addition to the proposed layouts, i would like to also support a
"personal" top-level where each person can put anything w/o worrying
about GUMM quality conformance (see below).

if you are interested in working on the mechanism side of things,
consider writing a GUMM node manager (combination client / server /
whatever freenet terminology is appropriate -- please educate me on this
and other freenet concepts as i am mostly ignorant).  this manager must
do the following things:

  - keep track of what modules are available at the node
  - map (forw/back) module names to local resources, allow aliases
  - define and implement a module serving protocol (simple)
  - define and implement a new-module acceptance protocol (hairy)
    - run analysis on the input
      - is it a "standard" (GNU auto tools supported) tarball?
      - is it a standalone chunk of code?
      - internal dependencies
      - external dependencies
      - what documentation is available? (reject if undocumented)
      - what self-tests are available? (reject if no self-tests)
      - what version scheme does it use? (x.y, x.y.z, random)
      - extract exports list / proc arity
      - complexity measurements / attempted compilation / etc
    - keep some history of the module if this node is "authoritative"
      - interface stability (exports list / arity / doc doesn't change)
      - last update / bit-rot alert
      - etc
  - vote tallying for module renaming (e.g., promotion from "personal"
    top-level to an official top-level)
  - scriptable w/ scheme (so that yours truly doesn't have to touch C :-)

actually the "reject if" clauses implement policy, so to be exact, the
mechanism side must be able to handle this policy...  in any case, it's
a good idea to try to keep mechanism/policy distinct in your mind and
designs (if not implementation ;-).

the GUMM node mananger should be the first module to be added to GUMM,
of course.  let me know if any of this strikes your fancy.  these ideas
are what i would do given the time/energy and are only suggestions, you
understand.

[i will update the GUMM page shortly to include this message.]

thi