#3762 closed task (fixed)

Determine what the new storage client HTTP protocol's version verb returns

Reported by: itamarst Owned by: GitHub <noreply@…>
Priority: normal Milestone: HTTP Storage Protocol
Component: unknown Version: n/a
Keywords: Cc:
Launchpad Bug:

Description

The protocol has a version endpoint. Should it return the same thing as the Foolscap protocol? Should be it bytes for keys? Unicode? Need to see exactly what Foolscap does, and if it's worth changing in any way.

Change History (4)

comment:1 Changed at 2021-08-16T20:28:10Z by exarkun

In my Haskell server, I modeled the Foolscap version response like this:

type ApplicationVersion = String

data Version1Parameters = Version1Parameters
  { maximumImmutableShareSize                 :: Size
  , maximumMutableShareSize                   :: Size
  , availableSpace                            :: Size
  , toleratesImmutableReadOverrun             :: Bool
  , deleteMutableSharesWithZeroLengthWritev   :: Bool
  , fillsHolesWithZeroBytes                   :: Bool
  , preventsReadPastEndOfShareData            :: Bool
  , httpProtocolAvailable                     :: Bool
  } deriving (Show, Eq, Generic)

data Version = Version
  { applicationVersion :: ApplicationVersion
  , parameters         :: Version1Parameters
  } deriving (Show, Eq, Generic)

I believe httpProtocolAvailable was an addition of my own and I think that we may since have decided not to try to advertise GBS that way. I think the rest of the fields correspond to what the current implementation does.

It ends up being a lot more than just a "version". Oh well?

Most of these fields are really descriptions of behaviors of the storage functionality of the server that might change (in practice I think only availableSpace is particularly dynamic - all of the bools changed from False to True or vice versa in some particular release and then never again and the other sizes have some default that no one ever bothers to override?). But there is that ApplicationVersion string.

Or, maybe more helpful is this fragment of Python that constructs the value:

        version = { b"http://allmydata.org/tahoe/protocols/storage/v1" :
                    { b"maximum-immutable-share-size": remaining_space,
                      b"maximum-mutable-share-size": MAX_MUTABLE_SHARE_SIZE,
                      b"available-space": remaining_space,
                      b"tolerates-immutable-read-overrun": True,
                      b"delete-mutable-shares-with-zero-length-writev": True,
                      b"fills-holes-with-zero-bytes": True,
                      b"prevents-read-past-end-of-share-data": True,
                      },
                    b"application-version": allmydata.__full_version__.encode("utf-8"),
                    }

comment:2 Changed at 2021-08-17T10:48:13Z by exarkun

Though it seems the Foolscap-based protocol uses bytes for all of the strings the strings are pretty clearly "text". It seems likely that byte strings were originally chosen (years and years ago) either by accident or without much consideration.

Since the initial goal of GBS is semantic equivalence, I think this is the version response we should go with - but I think unicode rather than byte strings makes sense here.

comment:3 Changed at 2021-12-01T14:10:40Z by itamarst

I feel like as a first pass maybe just send completely identical data? Seems easier.

comment:4 Changed at 2021-12-01T15:18:40Z by GitHub <noreply@…>

  • Owner set to GitHub <noreply@…>
  • Resolution set to fixed
  • Status changed from new to closed

In f7975b9/trunk:

Merge pull request #1161 from tahoe-lafs/3843-start-http-storage-server

A start at a HTTP-based storage server and client

Fixes ticket:3843
Fixes ticket:3762

Note: See TracTickets for help on using tickets.