[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
-
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [GNUnet-SVN] r27006 - gnunet-java,
gnunet <=