package client and server separately

[zooko]

​https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007084.html

​https://tahoe-lafs.org/pipermail/tahoe-dev/2012-March/007085.html

Here is a story that we should implement:

As a system administrator, I install the tahoe-lafs server software on a machine, and I know that since I didn't install the client software, the process running there will not import any code which is useful only to clients, will not open connections to other servers (which is #344), will not expose client-only services (which could be a security risk), and will not use up extra RAM or other computational resources to do client-only behavior. Also, installing the tahoe-lafs server doesn't depend on other software packages which are needed solely for the client.

Likewise, I can install the tahoe-lafs client software on a machine and have all the equivalent freedom from unexpected serverish behavior.

[zooko]

adding keyword p2p to tag tickets that have to do with the open question of "Is Tahoe-LAFS client-server or is it peer-to-peer?": pipermail/tahoe-dev/2012-July/007533.html

[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.