gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-SVN] r27006 - gnunet-java


From: gnunet
Subject: [GNUnet-SVN] r27006 - gnunet-java
Date: Tue, 30 Apr 2013 12:44:25 +0200

Author: dold
Date: 2013-04-30 12:44:25 +0200 (Tue, 30 Apr 2013)
New Revision: 27006

Modified:
   gnunet-java/ISSUES
Log:
issues

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2013-04-30 04:38:47 UTC (rev 27005)
+++ gnunet-java/ISSUES  2013-04-30 10:44:25 UTC (rev 27006)
@@ -1,34 +1,24 @@
+GNUNET_CRYPTO_get_host_identity: is it ok this way?
 
-* terminology in MQ is confusing (MQ_Message), any alternative suggestions?
+problems with stream,  other bug reports
 
+set should be mostly implemented, but will contain many bugs, since it's not 
yet tested
 
-* discuss splitting union/intersection implementation:
- * any alternative suggestion for the ugly set->extra.u->...?
+every time a set is destroyed, there should be a kind of garbage collection 
based on the generations
+(currently i just set and test for the generations, but never reclaim storage 
for older objects)
 
-* there's no convenient way to get the local peer's GNUNET_PeerIdentity
+different result modes:
+ * finishing a set operation in RESULT_FULL entails sending all local elements
+   of the creation generation of the operation, right?
 
-in the logs: Accepting connection on address@hidden/gnunet-se-�,�'
- * why is this garbled?
+test cases for mq:
+ * basic test cases are obvious
+ * stream is obvious (but stream has problems atm)
+ * how do i test mq for server-client, connection-client?
 
-# 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)
+GNUNET_CRYPTO_hkdf:
+ * not obvious which algorithms to use
 
+* elements received by a remote peer are kept seperate from the set's elements
 
-* 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
-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]