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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
in gnunet-java-ext there is a working example of a service and a corresponding client program, that actually work ;)
* simple greeting server, client gives name and server returns greeting
* illustrates using program/service, using the configuration, creating messages
* works with os control pipe / arm
arm-4477 WARNING Configuration file `(null)' for service `greeting' not valid: option missing
even when not using the signal pipe, does arm really kill processes?
* arm does never seem to send a sigkill if process does not respond
* sometimes arm command hangs!
$ gnunet-arm -c config/greeting.conf -k greeting -LDEBUG
Aug 29 19:25:22-808046 arm-api-5971 INFO Stopping service `greeting' within 60000 ms
Service `greeting' was already not running.
Aug 29 18:21:19-505909 arm-4751 ERROR Failed to start service `greeting'
Service `greeting' has been started.
logging with arm: what gets piped to where
* seems like service stdout->/dev/null, service stderr->arm stderr
Construct: has gotten very complex, i'm currently trying to trace a particular bug
* UPDATE: bug is gone!
* unit tests for construct have gotten better, still not good enough
* FrameSize
* recursive messages
* indirect recursion (over unions) (see core.SendMessage) works
* direct recursion has problems (see test/org.gnunet.construct.FrameSizeTest)
Question: Is all this too complicated? Should I invest the time to fix things as they are now intended, or should
we simplify?
* found some problems with timeouts in client/connection.
* should i write unit-tests for this timing-stuff?
* UPDATE: should be fixed now!
* program/service in general:
* how to handle the return value of main?
* java has no return value for main
* we must use System.exit(n) instead
* how about a (Program/Service).exit(n) that does cleanup and then calls System.exit(n)?
* configuration: what is $DEFAULTCONFIG? and CONFIG=?
mesh:
* we can't use multipe instances of org.gnunet.mesh.Mesh to test the API
* the local peer can't be the peer on the other end!
* the C-api has practically no coverage on mesh_api.c
* see below for a suggestion!
* LOCAL_TUNNEL_CREATE was used for two things, creating tunnels and being notified about incoming tunnels
* extending org.gnunet.testing so that multiple peers can be started and communicate with each other!
* the C-testing-api allows to create multiple peers, but they don't seem to be able to communicate with each
other!
* => the peers should somehow exchange their hellos / use a shared directory for the hellos
testbed vs testing: is this correct?
* testbed for large-scale testing across many "real" nodes
* testing for testcases on one host
* test coverage approaching a better state, any feedback?
* I think there should be some documentation in addition to the source code and the tutorial
* what would be the preferred format for such documentation? latex?
* (considering that they perhaps should end up on a website / should be browsable)
* examples:
* how do unions work in construct?
* other stuff in construct
* how does annotation processing work?
* project layout - what goes where
* as there is no standard java project layout
rationale for putting org.gnunet.testing in the src/-tree, not in test/:
* when developing an extension for gnunet-java, the developers may want to access the testing functionality from
the jar, so it should be included there!
* the code itself is tested, we want coverage etc.
* is there an effort to document what hostkeys files are etc.?
continuous integration: using Jenkins (=Hudson, forked away from Oracle)
* easier to configure than buildbot
* support for JUnit out-of-the-box
* support for cobertura via plugin
build system: still maintaining bash scripts, trying out gradle
* faster builds, build scripts far easier to read/write
* no integration with cobertura :(
* gradle has excellent Ant integration => Coverage (bash wrapper not very usable)
* can generate project files for eclipse/intellij
what's next?
* some actual stuff built with gnunet-java?
* general question: when should an api use per-connection receive, and per-service-receive?
does this make sense / do we need it:
* support in the scheduler for communicating asynchronously with other processes via stdin/stdout/stderr
* currently only used in testing, uses blocking i/o
* stream is implemented as a library, not as a service
* why?
* should GNUnet-java also implement it?
|
