[GNUnet-SVN] r28286 - gnunet-java

[gnunet]

Author: dold
Date: 2013-07-24 00:06:51 +0200 (Wed, 24 Jul 2013)
New Revision: 28286

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-07-23 21:45:32 UTC (rev 28285)
+++ gnunet-java/ISSUES  2013-07-23 22:06:51 UTC (rev 28286)
@@ -1,31 +1,50 @@
-* multihashmap_remove: value should be const, right?
+* i hit the problem of cyclic IBFs again ...
+ * identical subsequent keys => stop
+ * more than ibf->size elements decoded => stop
+ * similar rules apply to strata estimators
 
-* test_mesh_single
- * for communication over a single tunnel, mesh
-   delivered only the first message
- * currently seems broken again
+* running test_set_api is *the* way to trigger all kinds of mesh assertions!
 
-* set running and tested, gnunet-set-profiler works
- * stuff like cancel, ref-counting for set-ops implemented ;)
- * what should happen if the set's client disconnects? there is currently no 
error handler ...
- * yet missing: control flow; how to implement that nicely?
- * after quite some valgrinding and gdb, no memory leaks, no uninitialized 
memory (some were in mesh!)
-  * discovered the neat --db-attach
- * still random hangups due to mesh
- * I think it's safe to implement dv now
+* worst bug i've had in a long time:
+  https://gnunet.org/bugs/view.php?id=2967
+ * see 1st comment: I can't find any other reason than mesh!
 
-* as of this morning, mesh has problems again
+* discuss mesh tunnel auto reconnect
+ * bad for state-ful protocols
+ * shouldn't be transparent to the user
+ * there's almost no way for the connection to the service to be lost without
+   the mesh service crashing
 
-* consensus: 
- * mesh currently makes testing impossible
- * semi-honest consensus should work, modulo some bugs ;)
+* discuss set api issues from the bug tracker
+ * when is op cancel necessary?
+ * listener auto reconnect?
 
-* different set implementations now have a VTable 
- * not sure if the new implementation is better: it's shorter code-wise, but 
probably harder to
-   understand
+* in consensus, we need to present all elements to the client at the end of 
conclude
+ * => set now as GNUNET_SET_iterate
 
-* what C standard is GNUnet using?
- * C99 features? (struct initializers)
+* sounds easier than it is: iterating over a GNUNET_SET's elements.
+ * handling canceling for iterating over a set?
+ * flow control? memory overhead for queue?
+ * any idea how to implement iteration "better"?
 
-* TODO: update mesh in java
- * when mesh api is nicer
+* mq vs RequestQueue
+ * totally different approach
+ * queueing messages vs maintaining requests
+ * the latter is too complicated/contrived, let's go for mq!
+
+* context: how to do it in java?
+ * plain Object vs Tunnel<T>
+  * latter is nicer, currently implemented
+
+mq for *implementing* the mesh api:
+* observations about sending messages:
+ * messages are virtually never constructed in the ntr callback
+ * message construction is never costly
+ * the only reason I see for using ntr is that you can directly write
+   to a buffer. This argument does not apply to gnunet-java 
(org.gnunet.construct)
+  * does not apply to mesh; mesh does not even use the message size
+ * in java: notify transmit really clunky, why use it?
+
+* 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
+