3 - resume signalling for search/download must be recursive!
4 - deserialization code (download)
5 - serialization code (download)
6 - linking of downloads to searches (expose opaque struct SearchResult;
7 allow starting download based on search result (new API):
8 => have meta data for instant completion!
10 => linking of download to search
11 => expose link to search result in download events (including search result's
13 - generate SUSPEND events (publish, unindex, search, download)
14 - actually call 'sync' functions (publish, unindex, search, download)
16 => refactor fs.c to join common code segments!
17 => document directory structure
18 => ensure all files & dirs are cleaned up! (at least during 'clean' runs)
19 - persistence testing (publish, unindex, search, download):
21 => schedule suspending tasks DURING event handler => good coverage!
22 - gnunet-service-fs (hot-path routing, load-based routing, nitpicks)
23 - [gnunet-service-fs.c:208]: member 'LocalGetContext::results_bf_size' is never used
24 - [gnunet-service-fs.c:501]: member 'PendingRequest::used_pids_size' is never used
25 - [gnunet-service-fs.c:654]: member 'ConnectedPeer::last_client_replies' is never used
26 - [gnunet-service-fs.c:669]: member 'ConnectedPeer::avg_delay' is never used
27 - [gnunet-service-fs.c:675]: member 'ConnectedPeer::avg_priority' is never used
28 - [gnunet-service-fs.c:688]: member 'ConnectedPeer::pending_requests' is never used
29 - [gnunet-service-fs.c:694]: member 'ConnectedPeer::last_p2p_replies_woff' is never used
30 - [gnunet-service-fs.c:700]: member 'ConnectedPeer::last_client_replies_woff' is never used
32 + active reply route caching design & implementation of service; gap extension!
34 - on-demand encoding => move logic to block-library!?
35 - peer selection => how to consider latency/bw/etc?
36 - content transmission => how often the same block?
37 - how to select delay before next migration?
40 - integrate with FS or not? (peer list, index/on-demand encoding, block code,
41 inbound priority assignment; all would be easier with tight integration!)
43 - good to have for transport/DV evaluation!
45 - write DV API (need to move declarations from dv_api.c to gnunet_dv_service.h!)
46 - implement DV service
47 - implement DV library (looks done)
48 - implement DV transport plugin
50 - implement performance tests (needs tbench)
52 - needs more testing (especially F2F topology) & transport blacklisting
54 - only connect() sockets that are ready (select()) [Nils]
55 [On W32, we need to select after calling socket before doing connect etc.]
57 - use g_main_context_set_poll_func to integrate GTK with GNUnet Scheduler!? (YUCK!)
58 - OR: add scheduler API to enable integration with GTK main loop instead of doing our own select
59 - use g_main_context_pending, g_main_context_query / g_main_context_check / g_main_context_dispatch
60 and NEVER g_main_loop_run (can this be done? might be the clean way to do this! But how
61 to integrate this with "gtk_main"? Docu says:
62 "It's OK to use the GLib main loop directly instead of gtk_main(), though it involves
63 slightly more typing. See GMainLoop in the GLib documentation."
64 => so maybe it "just works"?
66 - design & implement new setup tool
70 - good to have for DV/DHT evaluation!
72 - implement DHT service
74 - implement performance tests
78 - need to get rid of synchronous API for service starts (cause all kinds of problems)
79 [=> eliminate for need to tell ARM about service starts most of the time!] [Safey]
80 - better tracking of which config changes actually need to cause process restarts by ARM.
81 - listen for requests to discover dependencies between services (and avoid
82 having to explicitly program start requests)
83 - better crash management (attach debugging support, capture and analyze
84 debug output, detect random vs. deterministic crashes)
87 - datastore reservation (publishing)
88 - location URIs (publish, search, download)
89 - utilize in-line files in meta data always (including in search results or
90 when download is triggered manually and for probes); currently the data is
91 only used when users do a general 'recursive' download
92 - non-anonymous FS service (needs DHT)
93 + DHT integration for search
94 + CS-DHT-functions (DHT-put of LOC)
95 + P2P-functions (DHT-get)
96 - collection API & tests
97 + gnunet-pseudonym (collection support)
98 - implement FS performance tests
104 - improved content selection (not just 'get_random')
107 * Determine RC bugs and fix those!
109 - modify configuration to allow controlling connections for non-local starts
110 - testbed creation with topology (needs working F2F topology)
112 - implement testcases for distributed testing
113 - test basic peer re-configure
114 - test topology creation
115 - test churn generation
116 - consider changing API for peer-group termination to
117 call continuation when done
119 - finalize API design
122 - integration with transport service
123 * MYSQL database backends: [CG]
127 - reconstruct IBLOCKS from DBLOCKS if possible (during download; see FIXME in fs_download)
132 - expand bibliography
133 - convert documentation pages to books
134 - update books (especially for developers)
135 - create good Drupal theme for GNUnet
136 - make a NICE download page and figure out how to enable developers to publish TGZs nicely
137 - port "contact" page
138 - add content type for "todo" items?
139 * POSTGRES database backends: [CG]
142 * Determine RC bugs and fix those!
146 - SMTP transport backend
147 - HTTPS transport backend
148 + improved HTTPS support in MHD
150 - Implement method of learning our external addresses from
151 other peers; need some kind of threshold-based
152 scheme, limiting both the total number of addresses that we accept
153 this way as well as requiring multiple confirmations; also, we
154 should possibly try to confirm that the given address works for
155 us ourselves (loopback-style) before adding it to the list
156 + we may be able to simplify WELCOME messages (no need to add
157 addresses there anymore, but may help to learn them there anyway...).
158 + we probably want some kind of voting/counting for learning IP addresses
159 (maybe including IP addresses in ads proportional to how often others
160 report them? we at least need some protection against >64k HELLOs!),
161 + provide a way to give the user a list of "learned" IP addresses and
162 a way to easily "veto" addresses off the list!
163 => If MiM attacker uses vetoed address, blacklist the specific IP for
164 the presumed neighbour!
165 - implement gnunet-transport (transport configurator / tester)
166 - UPnP-based IP detection
167 (Note: build library always, build service when libxml2/etc. are available)
169 - Remove KBlocks in gnunet-unindex (see discussion with Kenneth Almquist on gnunet-devs in 9/2009)
171 - expire 'ancient' HELLOs (those without valid addresses AND that
172 we have not 'used' (for their public keys) in a while; need a way
173 to track actual 'use')
174 - make sue we also trigger notifications whenever HELLOs expire
181 - should use hash map to look up sessions
183 - should use BIO instead of mmap
185 - need to periodically probe latency/transport cost changes & possibly switch transport
186 - should use hash map to look up Neighbours (service AND plugins!)
188 - check for duplicates on insertion (currently, same content is frequently
189 stored again [seen with KBLOCKS and SBLOCKS]!)
191 - merge multiple HELLOs of the same peer in the transmission queue
192 (theoretically reduces overhead; bounds message queue size)
193 - merge multiple iteration requests over "all" peers in the queue
194 (theoretically reduces overhead; bounds messgae queue size)
196 - use different queue prioritization for probe-downloads vs. normal downloads (!?)
200 - repeatedly resolve hostname and look up interfaces to determine our own IP
201 - [./transport/plugin_transport_tcp.c:391]: (style) struct or union member 'Plugin::address_update_task' is never used (related to issue above)
203 - [./transport/gnunet-service-transport.c:173]: (style) struct or union member 'TransportPlugin::rebuild' is never used (related to TCP not refreshing external addresses?)
205 - testcase would be nice...