[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-SVN] r30392 - gnunet-java
From: |
gnunet |
Subject: |
[GNUnet-SVN] r30392 - gnunet-java |
Date: |
Tue, 22 Oct 2013 08:06:24 +0200 |
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).
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r30392 - gnunet-java,
gnunet <=