[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-developers] my TODO list
From: |
Glenn McGrath |
Subject: |
[GNUnet-developers] my TODO list |
Date: |
Sat, 5 Apr 2003 14:12:57 +1000 |
Ive thought of a few things id like to do with GNUnet, aimed at
consolidating/improving existing work rather than adding new features.
1) Remove unnecessary macros.
I think its tidier to avoid macros as much as possible, one reason
being that the compiler cant do type checking on macro, apart from that
they tend to hide stuff that should be either a function or a variable.
2) Make transports a subdir of src/server
The transport libraries [udp, smtp, tcp] are only used by gnunetd so
they could go under the server directory.
3) Configuration options to link to shared rather than dynamic libraries
Dynamic loadable libraries are a useful idea in theory, but in
practice its often not needed.
I want to make it a configuration option whether to link specified
libraries to the binaries as a normal shared library or as a dynamic
library. I'm not sure how i want to implement it yet, it might get messy
if there are too many choices.
4) Cleaner seperation between gnunetd and applications
4a) Separate config file for gnunetd
It seems to me that splitting the configuration file is the easiest
way to make it simpler, splitting gnunetd config stuff out looks to be a
good separation point.
4b) Create a libgnunetd
Separate the gnunetd binary from its core functionality, probably
only have command line argument and config file parsing in the gnunetd
and the core functionality in the gnunetd library.
gnunetd, peer-info, transport check could link to this shared library.
6) Create a test framework for gnunetd
I think the bigest technical hurdle for gnunet is efficient use of
bandwidth, in particular cutting down unnecessary node-node chatter.
This chatter is something that will need to be tweaked and tuned as
GNUnet stabilises.
Christian spotted and fixed a problem when he hooked up about 35 (if
i remember correctly) nodes, it would be easier to find/fix problems if
we had an easy to setup test framework.
It would be good to be able see GNUnet's behaviour with hundreds or
even thousands of nodes.
A separate libgnunetd would make it easier to create a test
framework, as each local node could be passed its own config values
generated dynamically at startup.
I do need to think more about this one.
Comments ?
Glenn
pgpQHhDwxMidM.pgp
Description: PGP signature
- [GNUnet-developers] my TODO list,
Glenn McGrath <=