[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3761: Fake client/server pair implementing proposed GBS Python interface (part 1: immutables)

[Tahoe-LAFS]

#3761: Fake client/server pair implementing proposed GBS Python interface (part 1:
immutables)
--------------------------+-----------------------------------
     Reporter:  itamarst  |      Owner:  itamarst
         Type:  task      |     Status:  new
     Priority:  normal    |  Milestone:  HTTP Storage Protocol
    Component:  unknown   |    Version:  n/a
   Resolution:            |   Keywords:
Launchpad Bug:            |
--------------------------+-----------------------------------
Description changed by itamarst:

Old description:

> 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, and
> since having a (verified) fake implementation is useful for writing more
> isolated tests, a useful first step would be a `IStorageClient`
> implementation that is implemented in-process.
>
> The deliverables for this will be:
>
> 1. A new interface, `IStorageClient`, corresponding the the proposed HTTP
> protocol.
> 2. A compliance test suite for `IStorageClient` providers.
> 3. A (verified) fake `IStorageClient`. Since it won't talk over the
> network, there is no need for a separate server.
>
> It will be limited to immutables, with mutables in a follow-up ticket.

New description:

 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, and since
 having a (verified) fake implementation is useful for writing more
 isolated tests, a useful first step would be a `IStorageClient`
 implementation that is implemented in-process.

 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.

 It will be limited to immutables, with mutables in a follow-up ticket.

--

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