gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] my TODO list


From: leonard
Subject: Re: [GNUnet-developers] my TODO list
Date: Fri, 4 Apr 2003 22:44:39 -0500

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sat, 5 Apr 2003 14:12:57 +1000, Glenn McGrath <address@hidden> a miaulé :
> Comments ?

Yes, I'd also like to see nicer explanations in the config file,
forget the concepts and give concrete case->answers.
e.g: you want to share a directory, what argument and which DB style.
Thanks !

Leonard


Sat, 5 Apr 2003 14:12:57 +1000, Glenn McGrath <address@hidden> a miaulé :
> 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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+jlEnoqOw021SWZYRAmG+AJ98V8H3vNt2YTESbvxDqJQAl8ggSQCfZNEX
1zSYbyq+FcMNE2MFtlcUGtM=
=QQXx
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]