ISSUES


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

* I'm currently confused about the statistics API bug (from C), and how shutdown/disconnect is/should be handled.
* gnunet vs GNUnet, gnunet-java project name
* I'm currently trying to increase the robustness of the service APIs,
  discuss behavior in some cases
* packaging requirements


====================================================================

* IzPack is ~15MB, do we really want to have it in the svn repo?
No, env var.

* the Runabout can now be an anonymous inner class
 * implementation overhead: for public subclasses only constant overhead in the Runabout constructor
 * for private/anonymous inner classes: 10-20% overhead, measured over 100M calls
 * only issue left: visit methods have to be public, but this is a non issue.


* review the RequestQueue mechanism


* Statistics:
 * currently watches can't be canceled on the service level, only on the api level, is this intentional?
=> fine for now

* DHT:
 * getStart timeout does not really make sense (why timeout for transmission to the service,
   but not for retrieval of answers?)
   Is this just a documentation error?
=> fine to NOT have the timeout argument in the Java API

* core:
 * what happens if during a transmission the service disconnects? should we retry?
=> "no"

* with the changes in ARM there is no way to restart gnunet with arm if some client is misbehaving
=> SVN UP

* I'm often getting
  May 09 09:21:49-194786 util-11121 WARNING `socket' failed at connection.c:892 with error: Too many open files
=> SVN UP


==================

#!bin/sh
java -jar $GNUNET_JAVA_PREFIX/lib/gnunet.jar


==================

#!/bin/sh
if test -z $GNUNET_JAVA_PREFIX
then
  GNUNET_JAVA_PREFIX=%INSTALL_PREFIX%
fi
java -jar $GNUNET_JAVA_PREFIX/lib/gnunet.jar