-PHASE #1: (Goal: settle key design questions)
-
-Core:
-* API review: should "bpm" and "last_activity" arguments be
- included in the ClientEventHandler?
-* Internal: topology
-* Internal: advertising (propagate other peers' HELLOs, find new ones)
-* Internal: bootstrapping
- => bootstrap should use plugins, possible multiple at the same time!
-
-Util:
-* consider adding "get_time" to "configuration" API
-* improve disk API [Nils]
-
-TESTCASES WANTED:
-For these functions, it would be nice if we had testcases ("make check")
-that would cause them to be executed and check that they are working:
-* gnunet-service-peerinfo:
- - change_host_trust / flush_trust
- - remove_garbage /
- - discard_hosts_helper / cron_clean_data_hosts
-* gnunet-service-transport:
- - try_unvalidated_addresses
- - lookup_address_callback
- - lookup_hello_callback
- - plugin_env_lookup_address
- - notify_clients_disconnect
- - list_validated_addresses
- - cleanup_validation
- - disconnect_neighbour
- - handle_set_quota
-* plugin_transport_tcp.c:
- - tcp_plugin_cancel
- - tcp_plugin_address_pretty_printer / append_port
- - tcp_plugin_set_receive_quota
- - delayed_done
-* transport_api:
- - GNUNET_TRANSPORT_set_qutoa / send_set_quota
- - hello_wait_timeout
- - transmit_ready
- - transmit_timeout
- - remove_from_any_list / remove_neighbour
- - GNUNET_TRANSPORT_notify_transmit_ready_cancel
-* core_api:
- - timeout_request
- - solicit_traffic / copy_and_free
- - GNUNET_CORE_peer_configure / produce_configure_message
-* gnunet-service-core:
- - update_window
- - find_client
- - handle_client_request_configure
- - set_key_retry_task
- - align_and_deliver
- - handle_transport_notify_disconnect
-
-
-PHASE #2: (Goal: recover basic core functionality)
-
-Datastores:
-* implement sqlite-based sqstore/datastore service
- + implement library (talks to service)
- + implement service (datastore + talks to plugin)
- + implement sqlite plugin (talks to DB)
-* implement sqlite-based dstore services
- + implement library (talks to service)
- + implement service (talks to plugin)
- + implement sqlite plugin (talks to DB)
-
-Applications:
-* implement hostlist service (need to bootstrap!)
-* DHT, DV
-* FS / fs-libs
-
-Databases:
-* mysql & postgres backend
-
-Transports:
-* UDP backend (need LIBRARY to support (de)fragmentation!)
-* HTTP backend
-* Testing:
- + Testcases for set_quota, timeouts, disconnects, transmit_ready_cancel
- + Better coverage of gnunet-service-transport (hello validation)
- + direct test of plugins compliance to plugin API
-
-
-PHASE #3: (Goal: ready for pre-release) [completion-goal: end of 2009]
-
-* testing
-* setup
-* gtk, qt GUIs
-* tbench
-* tracekit
-* vpn
-
-
-
-Minor TODO items:
-* SERVER:
- - inefficient memmove
-* TRANSPORT:
- - transport_api: support forcing disconnects through low quotas!
- - API: consider having core provide priority and possibly
- deadline information for each message
- (likely important for DV plugin which wants to loop back!)
- - implement transport API to pretty-print transport address
- + transport_api extension (API extension!)
- + service-transport extension (protocol extension)
- - add calls to statistics in various places
- - implement gnunet-transport (transport configurator / tester)
- - UPnP-based IP detection
- (Note: build library always, build service when libxml2/etc. are available)
- - instantly filter addresses from *other* peers that
- are *equal* to our own address + port (i.e., localhost:2086). We
- no longer filter those for outgoing (helps with loopback testing
- and keeps the code clean), but we should filter strictly *impossible*
- incoming addresses! This is for efficiency, not correctness.
- - We currently are happy to take any address told to us in a WELCOME
- to our set of addresses; we should have some minimal threshold-based
- scheme, limiting both the total number of addresses that we accept
- this way as well as requiring multiple confirmations; also, we
- should possibly try to confirm that the given address works for
- us ourselves (loopback-style) before adding it to the list
- [SECURITY issue]
- - not sure current way of doing ACKs works well-enough
- with unreliable transports where the ACK maybe lost;
- the "is_new" check would then possibly prevent future
- ACKs to be delivered, all while we're happily
- receiving messages from that peer! Worse, the other
- peer won't generate another ACK since it thinks we're
- connected just fine...
- Key questions:
- + How necessary is ACKing in the first place? (alternatives?)
- + Should we transmit ACKs in response to every HELLO? (would that
- fully address the problem?)
- - latency measurements implemented in the transport
- plugins makes it only work for bi-di transports
- and results in code replication
- - should latency be included in the ReceiveCallback and
- NotifyConnect or passed on request?
-* SETUP:
- - auto-generate "defaults.conf" using gnunet-setup from "config.scm"
- - integrate all options into "config.scm"
- - change config-file writing to exclude options set to default values
-* ARM:
- - implement exponential back-off for service restarts
- - better tracking of which config changes actually need to cause process restarts by ARM.
- - have way to specify dependencies between services (to manage ARM restarts better)
-* PEERINFO:
- - have gnunet-peerinfo print actual host addresses again
- - add option to gnunet-peerinfo to modify trust value
-* POSTGRES-DB:
- - finish postgres implementation; simplify other SQLs using new stats
-* HTTPS transport
- - PolariSSL for MHD?
- - https integration
-* GAP improvements:
- - active reply route caching design & implementation of service,
- gap extension!
-
-=> PRE-RELEASE
-
-PHASE #4: [completion-goal: mid 2010]
-* Documentation
+Implementable right now (but not necessarily important), with caveats
+(unavailable components that will limit what can be implemented right
+away), in order in which they will likely be done:
+* TESTING
+* FS (DHT not available)
+* SETUP
+* DV (distributed testing not available)
+* TBENCH (distributed testing not available)
+* TRACEKIT (distributed testing not available)
+* HTTP transport
+* FRAGMENTATION
+* MySQL / Postgres plugins (datastore, datacache)
+* UPNP
+
+Urgent items (before announcing ng.gnunet.org):
+* FS (basic anonymous FS only)
+ - implement FS service (P2P operations)
+ + how to send queries (soliciting is not there in core; do we
+ also want to do pushing sometimes?)
+ + need to bound queueing of replies for other peers
+ - implement testcases
+ + sharing API
+ ~ file-information
+* CORE:
+ - soliciting traffic for clients that registered for it is not implemented
+ (in the service, client API supports GNUNET_MESSAGE_TYPE_CORE_SOLICIT_TRAFFIC
+ but never receives any such messages); how to avoid busy-waiting here
+ is a good question (solicit => nothing, when to solicit again???)
+* TESTING (needed for DV, DHT, Topology)
+ - implement library for local testing
+ + modify configuration to allow controlling connections for non-local starts
+ + CORE service does not start with valid peer ID (all zeros) -- testcase fails!
+ + consider changing API for peer-group termination to call continuation when done
+ - implement testcases for library
+ + get test for basic peer start to work!
+ + test basic peer connect
+ + test group start
+* TEST:
+ - topology (needs TESTING)
+ - hostlist (maybe easier with TESTING?)