configurable on/off storage server

[zooko]

It would be nice if you could run a Tahoe client without running a storage server.

​http://allmydata.org/pipermail/tahoe-dev/2007-October/000189.html

[warner]

so, you can mostly do this, by writing "0" into a file named 'sizelimit'. If you do that, you still wind up with a StorageServer? instance, but it will reject all lease requests.

We should make several changes here:

• if sizelimit==0, don't even create a StorageServer?. We need to modify the peer-selection code to not complain when callRemote("get_service", "storage") fails, so that this doesn't cause a lot of noise in the logs on both ends.
• Add a --no-storage or --storage or --storage-size-limit option to 'create-client', to make it easy to set this value at node-creation time.

[zooko]

We're focussing on an imminent v0.7.0 (see ​the roadmap) which hopefully has Small Distributed Mutable Files and also a fix for bad SHA-256. So I'm bumping less urgent tickets to v0.7.1.

[robk]

Brian and I just had a long discussion, incited by this ticket, about refactoring introduction.

Of the ideas discussed, the best seems to be to split introduction into publish and subscribe aspects (so that, e.g., storage servers can publish without subscribing, and storageless clients can subscribe without publishing) and along with that most probably to add 'type' information, so that objects published to the introducer are published as a specific type ('storage', 'login', 'encoder', 'checker' etc) and then consumers can subscribe to notifications of the types they're interested in.

This then retains a single-point of entry for configuration simplicity, while providing a flexible method for handling discovery of disparate types of services, and hence later extensions to new types of service.

[zooko]

Nice!

[zooko]

duplicate of #271

[zooko]

Milestone 0.7.1 deleted