[Top][All Lists]
[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-----