[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3761: Sketch of proposed GBS Python interface

[Tahoe-LAFS]

#3761: Sketch of proposed GBS Python interface
--------------------------+-----------------------------------
     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, 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.
>
> 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, 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.

--

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