[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1694: package client and server separately

Tahoe-LAFS trac at tahoe-lafs.org
Thu May 5 01:09:46 UTC 2016


#1694: package client and server separately
--------------------------+------------------------------------------------
     Reporter:  zooko     |      Owner:  somebody
         Type:            |     Status:  new
  enhancement             |
     Priority:  normal    |  Milestone:  undecided
    Component:            |    Version:  1.9.1
  packaging               |
   Resolution:            |   Keywords:  performance security packaging p2p
Launchpad Bug:            |
--------------------------+------------------------------------------------

Comment (by warner):

 I'm -1 on splitting client and server code apart so completely.. I
 recently started to do this with magic-wormhole, but Glyph talked me down.
 There are enough interdependencies between the client-ish pieces and the
 server-ish pieces that it'd be a difficult split: we'd need some third
 package (and a name on pypi) to hold all the things that are needed by
 both client and server distributions.

 And testing things would be more difficult. In the magic-wormhole
 experiment, I had a single git repo with multiple `setup.py` directories,
 and a `tox` config that attempted to install everything into a common
 virtualenv. It was messy.

 I'm not opposed to having a `tahoe-server` command that's used to do
 server-only things, and remove those subcommands from the client-centric
 `tahoe` command, but I don't think it'd be a win.

 I'm +1 on making a clear distinction between the behaviors of tahoe
 "clients" and "servers" (replacing the muddy concept of "node" with
 something that's definitely "client", or "server", or explicitly "both
 client+server"). So if you run `tahoe create-client`, then you can be sure
 that your process is not going to provide or advertise storage service
 (unless you subsequently modify tahoe.cfg to re-enable it). And `tahoe
 create-server` will refrain from connecting to storage servers because it
 doesn't need to. But in my current frame of mind, I'd like that to be
 controlled by tahoe.cfg, rather than having the code be absent entirely.

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


More information about the tahoe-lafs-trac-stream mailing list