[GNUnet-SVN] r26982 - gnunet-java

[gnunet]

Author: dold
Date: 2013-04-24 13:48:54 +0200 (Wed, 24 Apr 2013)
New Revision: 26982

Modified:
   gnunet-java/ISSUES
Log:
issues


Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-04-24 11:48:31 UTC (rev 26981)
+++ gnunet-java/ISSUES  2013-04-24 11:48:54 UTC (rev 26982)
@@ -1,21 +1,34 @@
-* i've seen multihashmap32, where is my multihashmap64? ;)
 
-* discuss set service
- * discuss how to split service into union/intersection
- * acknowledgement similar to (but simpler than) mesh
-  * other solution would be to use one client per request, not per set
-  * but, this demonstrates the features of GNUNET_MQ ;)
-* discuss GNUNET_MQ
- * message allocation
- * request tracking
- * notify sent
- * handling of timeouts
- * handling of incoming messages
- * any further suggestions?
+* terminology in MQ is confusing (MQ_Message), any alternative suggestions?
 
-* discuss gnunet-java build system
 
-* error-reporting in construct is really bad
- * add information to exception while bubbling up the parser tree
-  * only expensive on error
-(somewhat fixed already)
+* discuss splitting union/intersection implementation:
+ * any alternative suggestion for the ugly set->extra.u->...?
+
+* there's no convenient way to get the local peer's GNUNET_PeerIdentity
+
+in the logs: Accepting connection on address@hidden/gnunet-se-�,�'
+ * why is this garbled?
+
+# hack for mq.c, see automake Objects ‘created with both libtool and without’
+# remove one GNUNET_MQ is in util/
+gnunet_service_set_CFLAGS = $(AM_CFLAGS)
+
+* closures in GNUNET_SERVER_MessageHandler are not even used
+  once in gnunet -- thus GNUNET_MQ does not have a per-handler closure
+* the expected_size: we now have to check two different places to check
+  the right size of messages (handler declaration and handler cb)
+
+
+* we now have to store for each element whether it is remote or not, right?
+ * for the different result modes (all/new/removed)
+
+* should elements be returned to the client immediately for the union 
operation?
+* detecting collisions (each element on different peer)
+ * what hash do we use for this?
+* caching IBFs
+ * what strategies?
+* discuss how messages are / should be stored:
+ * per salt, IBFs and half-ibf-key=>ElementEntry map
+  * element entry stores ibf_key, element, ordered by ibf_key
+