devchat notes 04-Apr-2017

Brian Warner warner at lothar.com
Tue Apr 4 19:09:12 UTC 2017


Tahoe-LAFS devchat 04-Apr-2017

Attendees: warner, exarkun, meejah

Notes:

* JP had success with writing the foolscap proxy server from last week
* reviewed PR 375 (adds "tahoe status" command), will land
* potential future cleanups:
* all CLI commands accept e.g. "tahoe -d $NODEDIR subcommand", but the
  create-node/start/stop commands that refer to a node (rather than
  merely using one) also take $NODEDIR as a positional argument like
  "tahoe start $NODEDIR". This makes it easier for developers to spin up
  a bunch of nodes in a local testgrid (for i in NODE*; do tahoe start
  $i; done), but maybe that's not worth the implementation and --help
  docs confusion caused by having multiple places to set the same value.
  Test grids could be set up with a different shell script (for i in
  NODE*; do tahoe -d $i start; done)
* t=json should use Content-Type: application/json instead of
  text/plain. I originally wanted text/plain cause I wanted to be able
  to see the data in a web browser, and back then application/json
  forced browsers to download the data instead of displaying it. But
  modern browsers don't (in fact Firefox 53 gives you a nice structured
  tree view, with an option to see the raw text if you want).
* our CLI commands delay importing their implementations until the last
  minute (e.g. allmydata.scripts.cli.deepcheck does "from
  allmydata.scripts import tahoe_check" and then "tahoe_check()"). The
  idea (captured by a comment in startstop_node.py) was to enable "tahoe
  start --reactor=xyz" to work, which would require no twisted imports
  happen before "tahoe start" got control. But the comment also points
  out that this would be a lot of work, and I don't remember anyone
  complaining that they couldn't run tahoe with a non-default reactor,
  so maybe we can stop half-trying to support it. Maybe someday in the
  future we'll clean it all up.
* warner wants the api_auth_token to be all-hex, instead of urlsafe
  base64, but can't currently justify that. If I can come up with a good
  argument, I'll file a ticket and a patch. Note that api_auth_token is
  regenerated at each node startup, so we can safely change its format
  anytime we want.
* the API auth token is defined as not having a newline. The file it
  gets saved into does include one (for legibility of "cat
  NODEDIR/private/api_auth_token"), but clients should strip it out
  before sending. The server strips whitespace before comparing, so lazy
  clients would still work.

cheers,
 -Brian


More information about the tahoe-dev mailing list