[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2759: separate Tub per server connection

[Tahoe-LAFS]

#2759: separate Tub per server connection
------------------------------+-----------------------
     Reporter:  warner        |      Owner:  dawuud
         Type:  enhancement   |     Status:  new
     Priority:  normal        |  Milestone:  undecided
    Component:  code-network  |    Version:  1.10.2
   Resolution:                |   Keywords:
Launchpad Bug:                |
------------------------------+-----------------------

Comment (by warner):

 Landed step 1.. thanks!

 Looking at step 2: here's some thoughts:

 * which yaml library should we use? Could you update `_auto_deps.py` to
 add it's pypi name?
 * let's make `self.cache_filepath` into `self._cache_filepath`
 * should we use `yaml.safe_load()` instead of plain `load()`? (I don't
 know what exactly is unsafe about plain `load`, and we aren't parsing
 files written by others, but maybe it's good general practice to use
 `safe_load()` by default)
 * I didn't know about `FilePath.setContent()`.. that's cool, maybe we
 should replace `fileutil.write_atomically()` with it
 * at some point (maybe not now) we should put a helper method in
 `allmydata.node.Node` which returns the `NODEDIR/private/` filename for a
 given basename, so the magic string "private" isn't duplicated all over
 the place.
 * let's wrap the new long lines in test_introducer.py
 * we need a test that adds an announcement, then loads the YAML file and
 makes sure the announcement is present. Probably in
 `test_introducer.Announcements.test_client_*`, basically a
 `yaml.load(filename)` and checking that the announcement and key string
 are correct (including the cases when there is no key, because the sender
 didn't sign their announcement, or because it went through an old v1
 introducer)
 * we should also test duplicate announcements: I'm guessing that we want
 the YAML file to only contain a single instance of each announcement, and
 new announcements of the same server should replace the old one (instead
 of storing both). What's our plan for managing the lifetime of these
 cached servers? Do we remember everything forever? Or until they've been
 unreachable for more than X days? (in that case we need to store last-
 reached timestamps too).


 I like where this is going!

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2759#comment:16>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage