[GNUnet-SVN] r27876 - gnunet-java

[gnunet]

Author: dold
Date: 2013-07-10 14:33:08 +0200 (Wed, 10 Jul 2013)
New Revision: 27876

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-07-10 12:20:21 UTC (rev 27875)
+++ gnunet-java/ISSUES  2013-07-10 12:33:08 UTC (rev 27876)
@@ -1,27 +1,31 @@
-* doxygen comments are all fixed now ;)
+* multihashmap_remove: value should be const, right?
 
-Guess where to find the error:
-/home/dold/repos/gnunet/src/set/gnunet-service-set_union.c:1150: warning: 
Found unknown command `\parem'
-(of course, it's in gnunet-service-union.h!)
+* test_mesh_single
+ * for communication over a single tunnel, mesh
+   delivered only the first message
+ * currently seems broken again
 
-* MQ now has more documentation: https://gnunet.org/content/message-queue-api
+* 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
 
-* from the libtool manual, on how to use e.g. gdb with lt:
-  $ libtool --mode=execute gdb gnunet-bla
+* as of this morning, mesh has problems again
 
-* had quite a few problems with mesh
+* consensus: 
+ * mesh currently makes testing impossible
+ * semi-honest consensus should work, modulo some bugs ;)
 
-* src/consensus/gnunet-consensus-run-peers
- * obviously in wrong location. do you think it's useful/should be in 
src/testbed?
- * originally used to start a number of peers with services, and print
-   their config files so e.g. gnunet-consensus could connect manually.
+* 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
 
-set:
-* move as much logic as possible away
-  from the implementations
- * any comments/suggestion for improvement?
- * saw that cfuchs started with union
-* what about max. context message size?
- * a constant now
-* delayed listener issue
- * should work now
+* what C standard is GNUnet using?
+ * C99 features? (struct initializers)
+
+* TODO: update mesh in java
+ * when mesh api is nicer