[GNUnet-SVN] r30392 - gnunet-java

[gnunet]

Author: grothoff
Date: 2013-10-22 08:06:23 +0200 (Tue, 22 Oct 2013)
New Revision: 30392

Modified:
   gnunet-java/ISSUES
Log:
-answers

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-10-22 00:00:54 UTC (rev 30391)
+++ gnunet-java/ISSUES  2013-10-22 06:06:23 UTC (rev 30392)
@@ -44,17 +44,26 @@
  * as the ballot tool is not an API, doesn't it make most sense to have
    voting tests as shellscripts?
 
+YES.
+
  * how should FOREVER be handled in config files?
 
+There are keywords (NEVER, FOREVER, see util/strings.c).  I would probably
+for now not bother to check if the options are sane (i.e. vote finishes at 
eternity).
+
+
 Multiple authorities:
  * what should happen when duplicate vote is detected? where do we "complain"?
    (can't always detect this on submission, as two auth. might get different 
votes)
 
+GNUNET_log (WARNING)
 
  * When is the threshold crypto set up? Don't we need another
    time for when authorities start to set up the shared secret?
 
+True.
 
+
 exceptions and static initializers: when moving a class and not running 
'gradle msgtypes',
 this nice message pops up:
 
@@ -69,13 +78,27 @@
 
 Any idea on how to improve the error reporting?
 
+Not really.   Just don't have those issues in a release ;-).
+
+
 question on testbed service disconnect adapter:
  * why is this needed? I get the idea, namely that the operation of service 
connect
    is "canceled" (by calling done) and then the code for disconnecting is 
called, but why wouldn't
    I want to do this myself?
 
 
+For symmetry, and because testbed may want to trigger OTHER operations that
+were delayed (due to limited resources) until the disconnect was done.
+
+
 * crypto mismatch is a bit annoying, when will libgcrypt be done?
 
+WK and I talked yesterday. He said this weekend, or earlier.  There were some
+additional minor design issues to be discussed first...
+
+
 consensus+testbed test looks *horrible*, do you have any suggestions on how to 
improve?
 
+If you have a consensus command-line tool, you can try shell scripting
+instead (and use gnunet-testbed-profiler to start multiple peers from
+the shell).