[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1310: separate "gateway state directory" from "client state directory"

[Tahoe-LAFS]

#1310: separate "gateway state directory" from "client state directory"
-----------------------------------+-----------------------
     Reporter:  zooko              |      Owner:  warner
         Type:  defect             |     Status:  reopened
     Priority:  major              |  Milestone:  undecided
    Component:  code-frontend-cli  |    Version:  1.8.1
   Resolution:                     |   Keywords:  usability
Launchpad Bug:                     |
-----------------------------------+-----------------------

Comment (by warner):

 Hm. Ok, imagine this (I'm not sure I like it yet, but let's think about
 it):

 * emphasize well-defined boundaries of responsibility in non-server-side
 docs: "Gateway Process", "Agent Process", "CLI Tools" (oneshot)
 * users must create/configure the three things separately
 * first: `tahoe create-gateway GATEWAYDIR`. This directory holds human-
 edited config files and machine-edited state files, but only for gateway-
 related things: cached introducer data, server connection data, historical
 server reliability, etc. Maybe cached ciphertext (download caching, or
 upload caching to satisfy Shawn Willden's request for faster backup-and-
 shutdown handoff of responsibility from Agent to Gateway)
 * second: `tahoe create-agent AGENTDIR GATEWAYDIR`, where the AGENTDIR
 holds agent-related state, and the GATEWAYDIR is only used to figure out
 how to contact the gateway. Maybe `tahoe create-agent AGENTDIR GATEWAYURL`
 instead (except does it need to access anything else?).
 * third: `tahoe configure-clients CLIDIR GATEWAYURL`.

 Except:

 * how do we want to split responsibility between CLI (client) scripts and
 the gateway? Like, where should the encoding parameters be? When we add
 accounting, which side holds the key?
 * what about CLI scripts that are supposed to talk to the Agent instead of
 the Gateway? `tahoe configure-backup`?

 I kind of expect that tripling the number of commands that people have to
 run would roughly triple the perceived level of complexity, even if it
 exposes distinct components as separate conceptual entities in a way
 that's less confusing than conflating them.

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