[GNUnet-SVN] r28291 - gnunet-java

[gnunet]

Author: dold
Date: 2013-07-24 12:49:04 +0200 (Wed, 24 Jul 2013)
New Revision: 28291

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-07-24 10:48:53 UTC (rev 28290)
+++ gnunet-java/ISSUES  2013-07-24 10:49:04 UTC (rev 28291)
@@ -1,3 +1,9 @@
+* does GNUNET_FORCE_LOG work for log_from?
+ * set-api log messages dlog messages do not appear ...
+
+* consensus profiler and set shutdown:
+ * set is destroyed (shutdown!) before consensus, consensus still has listener
+
 * i hit the problem of cyclic IBFs again ...
  * identical subsequent keys => stop
  * more than ibf->size elements decoded => stop
@@ -18,6 +24,7 @@
 
 * discuss set api issues from the bug tracker
  * when is op cancel necessary?
+  * I got into the same problem as you (consensus!), so maybe the current API 
*is* bad ...
  * listener auto reconnect?
 
 * in consensus, we need to present all elements to the client at the end of 
conclude
@@ -33,6 +40,9 @@
  * queueing messages vs maintaining requests
  * the latter is too complicated/contrived, let's go for mq!
 
+* consensus in java: how would you represent / pass an
+  element w.r.t. missing const-correctness in java?
+
 * context: how to do it in java?
  * plain Object vs Tunnel<T>
   * latter is nicer, currently implemented
@@ -49,3 +59,7 @@
 * currently, in gnunet-java a mesh tunnel *is* a message queue with an 
additional notifySendReady
 * optional to use, otherwise queued messages are sent when mesh allows it
 
+* something does not let me run the consensus profiler when on a train ....
+  Jul 24 11:33:28-647361 testbed-api-topology-25801 WARNING Error while 
establishing a link: 0x4: Timeout while acquiring HELLO of peer 5MBM -- Retrying
+ * fixed, but why is this not the default?
+