[GNUnet-SVN] r27620 - gnunet-java

[gnunet]

Author: dold
Date: 2013-06-26 13:25:29 +0200 (Wed, 26 Jun 2013)
New Revision: 27620

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-06-26 10:58:54 UTC (rev 27619)
+++ gnunet-java/ISSUES  2013-06-26 11:25:29 UTC (rev 27620)
@@ -1,82 +1,27 @@
-The macro invocation
-  GNUNET_CONTAINER_DLL_remove (head, tail, head);
-does not work. had to learn this the hard way ;)
+* doxygen comments are all fixed now ;)
 
-MQ_Message is now MQ_Envelope
- * old name was confusing, now somewhat suggestive
+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!)
 
-(other rename: SET_evaluate is now SET_prepare, 
-as SET_connect and SET_evaluate both suggest something happens now,)
+* MQ now has more documentation: https://gnunet.org/content/message-queue-api
 
-added GNUNET_STREAM_mq_create ()
- * send-only mq, obviously
- * how to handle corking in the API?
+* from the libtool manual, on how to use e.g. gdb with lt:
+  $ libtool --mode=execute gdb gnunet-bla
 
-MQ structures are fully opaque
- * more of the logic moved to mq.c
- * implementations much shorter
- * review
+* had quite a few problems with mesh
 
-changed consensus_api.c to use MQ, much less code now
- * discovered API problem: when insert fails, insert done callback is
-   called with error indicator
- * _but_: inserts can be queued, and don't have to have an IDC
- * consensus should indicate failure in another way
-  * e.g. error handler in the constructor
+* 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.
 
-where are mesh ports defined? gnunet_applications.h?
-
-* how _exactly_ does corking work in mesh?
- * basic idea: merge multiple write calls to one message
- * what about flushing? timeouts? etc.
-
-* would anyone be offended if I add the doxygen strings to e.g. mesh_api.c?
- * vim jumps to the definition ;)
-
-* when is the initiator of a tunnel different from the message sender in mesh2?
-
-* return value of mesh2 message handler has unexpected semantics
-
-* what happens if the port we request in mesh is used?
- * lockmanager waits?
-  * what happens in only some ports are free?
-
-* mesh: shutdown not yet documented/implemented
-
-* simplest way to get random GNUNET_HashCodes with _fixed_ seed
- * I need this in set profiler to test if salting is correctly implemented
- * => find seed and salt that collides, and check if other salts don't collide
-
-* not being able to change mesh handlers per tunnel leads to somewhat ugly code
- * indirection due to the possible states of a tunnel
-  * connected incoming
-  * got peer's request
-  * client accepted request, client started request
-
-* issues with with tunnel context and tunnel_destroy: no way to get at the 
tunnel context
- * tunnel contexts have to be kept in a linked list as well
-   => more code, more bugs
-* if tunnel_destroy would call the tunnel end handler, there would
-  be no need to have/iterate through a linked list of contexts
-
-
-some gripes for gnunet-java and mesh:
- * ipc protocol is still very non-nice to use
-
-stuff about mesh2:
-* handlers have to be specified per connection to mesh
- * there's no reason to do this, except to safe sizeof(pointer) bytes per 
tunnel! 
- * makes SET very ugly (two "submodules" with different message types)
- * also would not work with plugins
- * my suggestion: drop the handlers array, use a single message handler instead
- * otherwise: how would you implement set intersection/union without code 
duplication?
-
-* handling of tunnel/connection death is not handled consistently across gnunet
- * why aren't mesh tunnels handled like SERVICE Clients?
- * need to keep state around for tunnels without
-
-* it's nowhere specified what tunnel buffering is
-* there's a comment in the source, but when will mesh have flow control?
-
-debugging: what is more recent, ./.libs/lt-foo or ./.libs/foo?
- * lt-foo seems to be created when foo is first executed?
+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