Sketch of proposed GBS Python interface

[itamarst]

In order to refactor the Tahoe-LAFS client code to support two protocols in parallel, we need some implementation of a new low-level client storage Python interface (let's call it IStorageClient). The production IStorageClient implementation will talk the GBS HTTP protocol to the storage server.

However, since the wire protocol is going to have to be audited, a useful first step would be a IStorageClient sketch that just demonstrates what a Python API might look like, and how it would integrate.

The deliverables for this will be:

1. A new interface, IStorageClientV2, corresponding the the proposed HTTP protocol.
2. Implement adapter from IStorageServer to IStorageClientV2. Might not be code that is tested or runs, but should at least suffice to demonstrate that this approach is viable.

Potential follow-ups:

• Update all existing users of IStorageServer to not presume Foolscap, so e.g. don't assume commands are executed in order sent.
• A compliance test suite for IStorageClientV2 providers.
• Maybe? A (verified) fake IStorageClientV2. Since it won't talk over the network, there is no need for a separate server.

[itamarst]

Because lease logic is still being discussed, I decided to just stick to current structure with the presumption that because lease logic is fairly minimal and not used much, fixing it later won't be a big deal.

[itamarst]

After further thought: it seems like one could actually port Foolscap-based code to talk to an implementation of the interface that is just a facade using Foolscap behind the scenes. So giong to try this, because if that works and is easy, dropping in HTTP will be easy.

[itamarst]

After further thought: is this just what IStorageServer already is? A Python-y wrapper around RIStorageServer, the Foolscap-specific interface.

[itamarst]

IStorageServer is actually pretty close for immutables; will look at mutables next. So plausibly could make HTTP-based IStorageServer implementation and not change existing code.

There's a caveat though: the current implementation has Assumptions, namely that:

1. Method calls happen _sequentially_, since it's all over the same TCP connection.
2. Some method implementations are synchronous on the server(!!!).

For example, ​https://github.com/tahoe-lafs/tahoe-lafs/blob/0125deb6032369ca19e0f098719bc49129eec35f/src/allmydata/mutable/servermap.py#L611

So the real work may be:

1. Going through the code and manually auditing it for places where these assumptions hold.
2. Perhaps simulating arbitrary delays in messages to automatically find places in the code that make this assumption.

[itamarst]

Another option is IStorageServer that is backed by HTTP and ensures calls are sequential with the same semantics as Foolscap. At a guess that would be a single persistent HTTP connection with pipelining (the latter being not strictly necessary, but important for performance).

[itamarst]

Twisted doesn't have HTTP/1.1 pipelining anymore, and HTTP/2 is multiplexed, not pipelined, so can't rely on being sequential (Twisted support is unclear).

[itamarst]

(Moved to #3779).