[GNUnet-SVN] r23519 - gnunet-java

[gnunet]

Author: grothoff
Date: 2012-08-30 08:54:32 +0200 (Thu, 30 Aug 2012)
New Revision: 23519

Modified:
   gnunet-java/ISSUES
Log:
answers

Modified: gnunet-java/ISSUES
===================================================================
--- gnunet-java/ISSUES  2012-08-30 00:49:00 UTC (rev 23518)
+++ gnunet-java/ISSUES  2012-08-30 06:54:32 UTC (rev 23519)
@@ -4,6 +4,8 @@
  * illustrates using program/service, using the configuration, creating 
messages
  * works with os control pipe / arm (see below for problems with arm)
 
+RE: Great.
+
 * i tried merging gnunet-testing and gunet-testing-run-service, but failed :(
  * gnunet-testing-run-service uses GNUNET_TESTING_service_run
   * which can't be run from within the main called by GNUNET_PROGRAM_run (as 
the scheduler is already running)
@@ -12,23 +14,44 @@
   * so what about the default arguments?
  * does it really make sense to merge them, functionality-wise?
 
+RE: Hard to say; while there are ways to work around the problem you mention, 
there is clearly
+no need for great hacks to force the merge; let's leave them separate.  Maybe 
rename gnunet-testing-run-service
+to gnunet-helper-testing-run-service to make clear that it is a "helper" 
process and not something meant to be
+run by users from the command-line...
+
+
 arm-4477 WARNING Configuration file `(null)' for service `greeting' not valid: 
option missing
 
+RE: you need an entry "CONFIG = $DEFAULTCONFIG" in [greeting] in your 
greeting.conf[.in]
+
+
 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!
 
+RE: ARM waits for the child to terminate, this would seem like hanging; when 
not using a signal pipe,
+ARM will send a POSIX signal and then do "wait".  What happens is then up to 
the child...
+
+
  $ 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.
 
+RE: might relate to the 'CONFIG' option missing above...
 
 Aug 29 18:21:19-505909 arm-4751 ERROR Failed to start service `greeting'
 Service `greeting' has been started.
 
+RE: Again, this might relate to the 'CONFIG' option missing above, but is the 
inconsistency of
+the messages given is certainly a bit odd.  Should be investigated.
+
 logging with arm: what gets piped to where
  * seems like service stdout->/dev/null, service stderr->arm stderr
 
+RE: stdout should never be used by services, especially not for logging; where 
'stderr' goes (logfile, arm's stderr)
+depends on the configuration;
+
+
 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
@@ -40,6 +63,9 @@
 Question: Is all this too complicated? Should I invest the time to fix things 
as they are now intended, or should
 we simplify?
 
+RE: How would you simplify it? I don't recall us having significant 
unwanted/unnecessary functionality, do we? 
+
+
 * found some problems with timeouts in client/connection.
  * should i write unit-tests for this timing-stuff?
  * UPDATE: should be fixed now!
@@ -50,51 +76,79 @@
  * we must use System.exit(n) instead
  * how about a (Program/Service).exit(n) that does cleanup and then calls 
System.exit(n)?
 
+RE: the user writes a 'main' function which (usually indirectly via 
program/service) invokes the
+    scheduler; after that invocation returns to 'main', 'main' should call 
System.exit(RV).  I don't
+    see a need to integrate this call with org.gnunet.util.
+
 * configuration: what is $DEFAULTCONFIG? and CONFIG=?
 
+RE: it is possible to pass a custom configuration file for one of the 
services, instead of using the
+same configuration file for all services; rarely used feature.  $DEFAULTCONFIG 
== "this 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!
+RE: why not? C tests do this AFAIK.
   * the C-api has practically no coverage on mesh_api.c
+RE: don't understand
   * see below for a suggestion!
  * LOCAL_TUNNEL_CREATE was used for two things, creating tunnels and being 
notified about incoming tunnels
+RE: that sounds, eh, not great... => check with Bart?
 
 * 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!
+RE: Matthias said that transport was having trouble again these days...
  * => the peers should somehow exchange their hellos / use a shared directory 
for the hellos
+RE: yes, you'll need transport API implementations to call 'try_connect' and 
to get and exchange HELLOs
 
  testbed vs testing: is this correct?
   * testbed for large-scale testing across many "real" nodes
   * testing for testcases on one host
+RE: Almost right;  testing is a little helper library for testbed, useful for 
small-scale tests with
+   simple setups; testbed is for multi-host deployments AND for more complex 
single-host setups
+   (specific network topologies, etc.)
 
 * test coverage approaching a better state, any feedback?
+RE: buildbot integration to run against C SVN HEAD would be nice to have...
 
 * 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?
+RE: JavaDoc for API documentation; HTML on website for code overview-level 
stuff, LaTeX for
+   tutorial; we might also write something more like a paper in LaTeX at some 
point, but 
+   I'm not sure about that yet; 
  * (considering that they perhaps should end up on a website / should be 
browsable)
  * examples:
   * how do unions work in construct?
+RE: JavaDoc and a webpage on Construct in HTML 
   * other stuff in construct
+RE: => webpage on Construct in HTML 
   * how does annotation processing work?
+RE: => sub-section in webpage on gnunet-java build system
   * project layout - what goes where
    * as there is no standard java project layout
+RE: => code overview chapter in webpage on gnunet-java
 
 
 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.
+RE: both are good reasons.
 
 * is there an effort to document what hostkeys files are etc.?
+RE: not yet, might not be a bad idea; do you want to write something? :-)
 
 continuous integration: using Jenkins (=Hudson, forked away from Oracle)
  * easier to configure than buildbot
  * support for displaying JUnit reports out-of-the-box
  * support for cobertura via plugin
  * but not very stable
+RE: is that a suggestion or something you already finished? If not finished, 
did you try it? (just asking...)
 
 for junit reports we need ant/gradle!
+RE: I saw the gradle build file.
 
 build system: still maintaining bash scripts, trying out gradle
  * faster builds, build scripts far easier to read/write
@@ -103,17 +157,28 @@
  * gradle has excellent Ant integration => Coverage (bash wrapper not very 
usable)
  * can generate project files for eclipse/intellij
  * would make stuff like installing gnunet-java from source easier than using 
izpack
+RE: As the gradle config is trivial, no harm in *also* having it; not sure 
about 
+    obsoleting izpack (as izpack is the template for an installer for 
end-users,
+    not for eclipse integration...); maintaining two build systems (one for 
cobertura,
+    one for ant/eclipse/junit/jenkins?) might be OK, but of course is not 
ideal.
 
 what's next?
  * some actual stuff built with gnunet-java?
+RE: Yes.  Krista is supposed to e-mail you some papers to read, then we'll 
decide on some fun protocol to implement!
 
+
 * general question: when should an api use per-connection receive, and 
per-service-receive?
+RE: I don't understand the question.
 
 does this make sense / do we need it:
  * support in the scheduler for communicating asynchronously with other 
processes via stdin/stdout/stderr
+RE: see util's helper API in C -- that's where we do use this; so _eventually_ 
we might want this.
   * currently only used in testing, uses blocking i/o
+RE: blocking IO is always deadly eventually; so we should probably add async 
IO for pipes to Java scheduler
 
 * stream is implemented as a library, not as a service
  * why?
+RE: various reasons, performance, KISS, statelessness of a stream, ...
  * should GNUnet-java also implement it?
+RE: maybe, but certainly not yet, stream is still to experimental anyway