if/when the property "timestamper.enabled" is set, the timestamper will query the sntp server(s) and update the clock accordingly
if/when it is not set (or set to something other than "true"), it will pause with its standard delay before checking again
in addition, it has a guard to help running the timestamper multiple times in the same JVM
new piece of data exposed and maintained is a list of router contexts - shown as a singleton off RouterContext - allowing an app in the same JVM to find the routers (and chose between which one they want)
one for peer selection and organization. reliability is kept around
for the moment and shown on the router console, but only to provide a
comparison (it is not used in any way)
* new stat in the TunnelHistory: failRate
* coallesce TunnelHistory stats (duh!)
* new ProfileOrganizer CLI ("ProfileOrganizer[ filename]*"
* implement reasonable 'failure' logic - if they are actively rejecting
tunnels or tunnels they've agreed to are failing, mark them as failing
* when choosing peers to test, exclude all fast ones
Some of them think that its ok for an inner class of a subclass to access protected data of the
outer class's parent when the parent is in another package.
Others do not.
Kaffe doesn't care (but thats because Kaffe doesn't do much for verification ;)
The JLS is aparently confusing, but it doesnt matter whether its a code or javac bug, we've got to change the code.
The simplest change would be to just make the JobImpl._context public, but I loath public data, so we make it private and add an accessor
(and change dozens of files)
whee
if more tokens become available while the first pending request is still blocked on
read/write (aka after allocation and before next .waitForAllocation()), give the tokens
to the next request
* refactor the satisfy{In,Out}boundRequests methods into smaller logical units
