1 files changed, 79 insertions, 221 deletions

diff --git a/ISSUES b/ISSUES
index 2528f68..4b5544d 100644
--- a/ISSUES
+++ b/ISSUES
@@ -1,248 +1,106 @@
 
-* I'm currently confused about the statistics API bug (from C), and how shutdown/disconnect is/should be handled.
-* gnunet vs GNUnet, gnunet-java project name
-* I'm currently trying to increase the robustness of the service APIs,
-  discuss behavior in some cases
-* packaging requirements
+in gnunet-java-ext there is a working example of a service and a corresponding client program, that actually work ;)
+ * simple greeting server, client gives name and server returns greeting
+ * illustrates using program/service, using the configuration, creating messages
+ * works with os control pipe / arm
 
+arm-4477 WARNING Configuration file `(null)' for service `greeting' not valid: option missing
 
-====================================================================
+even when not using the signal pipe, does arm really kill processes?
+ * arm does never seem to send a sigkill if process does not respond
+ * sometimes arm command hangs!
 
-* IzPack is ~15MB, do we really want to have it in the svn repo?
-No, env var.
+ $ gnunet-arm -c config/greeting.conf -k greeting -LDEBUG
+ Aug 29 19:25:22-808046 arm-api-5971 INFO Stopping service `greeting' within 60000 ms
+ Service `greeting' was already not running.
 
-* the Runabout can now be an anonymous inner class
- * implementation overhead: for public subclasses only constant overhead in the Runabout constructor
- * for private/anonymous inner classes: 10-20% overhead, measured over 100M calls
- * only issue left: visit methods have to be public, but this is a non issue.
 
-* review the RequestQueue mechanism
+Aug 29 18:21:19-505909 arm-4751 ERROR Failed to start service `greeting'
+Service `greeting' has been started.
 
-* Statistics:
- * currently watches can't be canceled on the service level, only on the api level, is this intentional?
-=> fine for now
+logging with arm: what gets piped to where
+ * seems like service stdout->/dev/null, service stderr->arm stderr
 
-* DHT:
- * getStart timeout does not really make sense (why timeout for transmission to the service,
-   but not for retrieval of answers?)
-   Is this just a documentation error?
-=> fine to NOT have the timeout argument in the Java API
+Construct: has gotten very complex, i'm currently trying to trace a particular bug
+ * UPDATE: bug is gone!
+ * unit tests for construct have gotten better, still not good enough
+ * FrameSize
+ * recursive messages
+  * indirect recursion (over unions) (see core.SendMessage) works
+  * direct recursion has problems (see test/org.gnunet.construct.FrameSizeTest)
 
-* core:
- * what happens if during a transmission the service disconnects? should we retry?
-=> "no"
+Question: Is all this too complicated? Should I invest the time to fix things as they are now intended, or should
+we simplify?
 
-* with the changes in ARM there is no way to restart gnunet with arm if some client is misbehaving
-=> SVN UP
+* found some problems with timeouts in client/connection.
+ * should i write unit-tests for this timing-stuff?
+ * UPDATE: should be fixed now!
 
-* I'm often getting
-  May 09 09:21:49-194786 util-11121 WARNING `socket' failed at connection.c:892 with error: Too many open files
-=> SVN UP
+* program/service in general:
+ * how to handle the return value of main?
+ * java has no return value for main
+ * we must use System.exit(n) instead
+ * how about a (Program/Service).exit(n) that does cleanup and then calls System.exit(n)?
 
+* configuration: what is $DEFAULTCONFIG? and CONFIG=?
 
-==================
+mesh:
+ * we can't use multipe instances of org.gnunet.mesh.Mesh to test the API
+  * the local peer can't be the peer on the other end!
+  * the C-api has practically no coverage on mesh_api.c
+  * see below for a suggestion!
+ * LOCAL_TUNNEL_CREATE was used for two things, creating tunnels and being notified about incoming tunnels
 
-#!bin/sh
-java -jar $GNUNET_JAVA_PREFIX/lib/gnunet.jar
+* extending org.gnunet.testing so that multiple peers can be started and communicate with each other!
+ * the C-testing-api allows to create multiple peers, but they don't seem to be able to communicate with each
+   other!
+ * => the peers should somehow exchange their hellos / use a shared directory for the hellos
 
+ testbed vs testing: is this correct?
+  * testbed for large-scale testing across many "real" nodes
+  * testing for testcases on one host
 
-==================
+* test coverage approaching a better state, any feedback?
 
-#!/bin/sh
-if test -z $GNUNET_JAVA_PREFIX
-then
-  GNUNET_JAVA_PREFIX=%INSTALL_PREFIX%
-fi
-java -jar $GNUNET_JAVA_PREFIX/lib/gnunet.jar
+* I think there should be some documentation in addition to the source code and the tutorial
+ * what would be the preferred format for such documentation? latex?
+ * (considering that they perhaps should end up on a website / should be browsable)
+ * examples:
+  * how do unions work in construct?
+  * other stuff in construct
+  * how does annotation processing work?
+  * project layout - what goes where
+   * as there is no standard java project layout
 
 
+rationale for putting org.gnunet.testing in the src/-tree, not in test/:
+ * when developing an extension for gnunet-java, the developers may want to access the testing functionality from
+   the jar, so it should be included there!
+ * the code itself is tested, we want coverage etc.
 
-===========================================================
+* is there an effort to document what hostkeys files are etc.?
 
-* @UNIXONLY@ PORT = 2089 in src/util/resolver.conf.on
- * what's the purpose? we also need this line to be enabled on JAVAPORT
+continuous integration: using Jenkins (=Hudson, forked away from Oracle)
+ * easier to configure than buildbot
+ * support for JUnit out-of-the-box
+ * support for cobertura via plugin
 
-* something I didn't think through from the beginning:
-  how should unknown message types be handled by message handlers?
- * sometimes we want to see the message (e.g. in server), sometimes it is an error
- * alternative 1: signal an error to the message handler, somehow pass the original message
- * alternative 2: pass a special UnknownMessage to the message handler, filter it for higher-level
-   APIs and signal an error.
+build system: still maintaining bash scripts, trying out gradle
+ * faster builds, build scripts far easier to read/write
+ * no integration with cobertura :(
+ * gradle has excellent Ant integration => Coverage (bash wrapper not very usable)
+ * can generate project files for eclipse/intellij
 
+what's next?
+ * some actual stuff built with gnunet-java?
 
-* the recvDone is kind of clunky (see test/org.gnunet.util.ServerExample)
+* general question: when should an api use per-connection receive, and per-service-receive?
 
-* finally core/statistics/dht/resolver/... have unit tests!
-  (and coverage works again, but i can't access the cobertura via ssh yet)
- * currently most test rely on a running gnunet, and use the default configuration
- * alternative approach:
-  * configuration is copied from resource (may be in a jar!) to a temp file, then passed on the command
-    line to gunet-service-*
-  * useful to test behavior on disconnects
-  * problem: java sucks at managing processes, processes stay alive if we abort a test
- * dht get: can we assume that "our" peer immediately stores the value?
+does this make sense / do we need it:
+ * support in the scheduler for communicating asynchronously with other processes via stdin/stdout/stderr
+  * currently only used in testing, uses blocking i/o
 
-* naming: when do we use destroy, when do we use disconnect, or is this arbitrary?
-  start-stop, create-destroy, connect-disconnect; constructor: fine, destructor: see C API
+* stream is implemented as a library, not as a service
+ * why?
+ * should GNUnet-java also implement it?
 
-* implications of using exceptions in callbacks
- * esp. when the exception is non-fatal, i.e. the exception is caught, handled, and the program continues
- * java exceptions have no restarts, may leave gnunet-java in inconsistent state; FINALLY!
-
-* how to test callbacks? we do not only need to test for the right values, but also check that callback has actually
-  been called.
- * first approach: thow a TestSuccess exception, discarded (see above)
- * current approach: build a list of assertions, check assertions after scheduler is done.
-  * each assertion stores whether it already succeeded and a message
-
-
-* finalziers: used to destroy object. lead to heisenbug/double disconnect. now policy: check if object
-  has been disposed of properly, otherwise log a warning.
- * cannot guarantee cleanup anyway
-   (java behavior: run finalizers iff unreachabla during gc, may never happen, finalizers on jvm shutdown deprecated)
-
-
-* regarding peerinfo
-  * i don't fully understand how HELLOs work.
-
-* what are the next important services to implement? (probably mesh, peerinfo, transport)
-
-
-* i'm currently considering to use the google guava library
- * Apache License 2.0
- * con: large (1.8MB jar)
-  * but: unused class files could be stripped from the jar, e.g. using ProGuard
- * would replace the apache commons io library
- * contains collections used throughout gnunet
-  * bloomfilter
-  * multimap, alleviates the boilerplate code when dealing with hashmaps of lists
- * methods to deal with "signed" primitives
- * dealing with files (e.g. copying)
- * redirecting i/o streams from/to files (when issuing external commands)
- * hashing utilities
- * tables (mapping from key pair to value), would replace nested Maps in e.g. Configurations
- * ...
-
-
-
-
-* long-term todos:
- * refactor the Construct implementation, implement the "nicer" syntax
- * refactor the getopt implementation
-
-
-
-
-============================================================
-
-* tests now run on the cobertura account :)
- * see https://gnunet.org/cobertura/
- * gnunet needs to compiled with --disable-nls to work on the server
- * cronjob added
- * could/should we report the success of JUnit tests?
-  * (as somehow my bugs only seem to show when running on another system ;)
-
-* gnunet-java now can now start/restart services for testing with the testing wrapper executable
- * i duplicated the code for GNUNET_TESTING_service_run_restartable
-  * now passes the Peer to main, which can start/stop it
-  * probably also should pass the config file name (not only the handle)
-   * how about a GNUNET_TESTING_peer_get_config_path?
- * what about windows?
-
-* server/service:
- * needed for testing the server: getting an unused port with java
- * how do we test the signal pipeline?
-  * probably with runin arm in a testing peer, but then we would also have to talk to arm
-
-
-the following notes are old:
-* we are still not able to test "temporary destruction"
- * because every time a new port may be generated
- * we need a way to kill a service and run it with the same config
- * now implemented!
-* review if everything in Makefile.am is correct
- * what is *_DEPENDENCIES vs *_LDADD?
-* how do we get a handle to stdin (in a non-hacky way) that can be selected on by scheduler?
-* c-getopt question: GNUNET_GETOPT_run returns index of first non-option.
-  so options and non-options may not be mixed?
-* i have to manually write the config file, why isn't there a way to get the
-  file name, not just the ConfigurationHandle?
-* could we get a confirmation that a service *really* is dead?
- * or is this guaranteed if TESTING_service_run returns?
- * otherwise there is no way to reliably test behavior on interrupted connection
-* TESTING_service_run does not indicate that the service could not be run!
- * just logs an error
- * currently we check availability of data on stderr.
-
-
-PEERINFO_GET vs PEERINFO_GET_ALL
- * if we have PEERINFO_GET_ALL, why is the peer-field in ListPeerMessage(with type=PEERINFO_GET) empty?
-
-
-* are peerinfo requests queued?
- * i remember discussing peerinfo as a compilicated example for a general message queueing implementation. why?
- * if we have to queue: how about a "choke/release" for the outgoing message queue?
-  * otherwise we don't know which requests belongs to which response
-* can peerinfo return more than one record per peer?
-
-
---------------------------------------------------------------
-
-* see mantis for problem with the signal pipe
-
-* what should the gnunet-testing-run-server tool be called, now that
-  there already is plain gnunet-testing?
-
-* where should TESTMessage and HELLOMessage, PeerIdentity, HashCode go?
- * and do we want to call them TESTMessage or TestMessage?
-
-* had a bug in the IPv6 address parsing code
- * tried to fix it / rewrite it, eventually got frustrating
- * found out guava has an implementation of this :)
-  * also implements shortening (like ::1)
-  * by reading the code: implementing all this correctly would not have been a fun time
-
-* TestingServer now allows the client/connection/server to be tested easily
- * found quite some bugs during this
-
-* thoughts about exponential backoff / the client-connection stuff in GNUnet and gnunet-java
- * why do we wait the entire backoff period, if the connection could be available earlier?
-
-* discuss what mesh does, what transport does
- * i found the documentation for transport on gnunet.org
- * the is not much information about mesh, except for the source code
-
----------------------------------------------------------------
-
-* reference count / receive_done behavior is a bit strange / confusing
- * clients are disconnected only when refcnt==0 *and* shutdown is requested?
- * behavior on receive done: when success=1 but refcnt=0, why don't we disconnect the client?
-
-   /**
-    * Was processing if incoming messages suspended while
-    * we were still processing data already received?
-    * This is a counter saying how often processing was
-    * suspended (once per handler invoked).
-    */
-
-I don't understand that comment!
-
-
-
-* im currently confused about the different layers of GNUnet / I don't get the big picture
- * e.g. transport's distance vector plugin vs mesh
- * peerinfo / mesh
- * assuming a large network, doesn't a client have to store a large amout of information?
-
-* how to test MESH?
- * maybe talk to Harsha about testbed? :)
-
-* interesting things happen with JUnit
- * failure of one test causes timeout in another
-
-* review org.gnunet.testing
-
-cp a x ; cp b x
-is not the same as
-cp b x ; cp a x
-if x does not exist prior to copying