[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3901: End-to-end support for new HTTP storage protocol: tracking issue

[Tahoe-LAFS]

#3901: End-to-end support for new HTTP storage protocol: tracking issue
--------------------------+-----------------------------------
     Reporter:  itamarst  |      Owner:
         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:

> Each of these will be zero or more additional tickets:
>
> 1. Storage nodes can be started with HTTP protocol (It is maybe possible
> but not worth doing to do this via storage plugin.)
> 2. Storage nodes send the NURL to an introducer, in addition to the fURL
> for legacy Foolscap protocol. This is sent as an announcement upgrade so
> it supercedes existing announcement.
> 3. The introducer sends NURLs to storage clients. INVARIANT: old storage
> clients can safely get and ignore NURLs. If this is not the case, some
> conditional logic needs to be introduced so old clients don't get NURLs.
> 4. The storage client understands NURLs, and use HTTP protocol instead of
> Foolscap when possible. See design doc for further discussion (QUESTION:
> is it actually possible to say "this furl and nurl are for the same
> server"? technically, maybe but not necessary given announcement
> upgrades).
> 5. Currently the storage client caches per-server FURLs indefinitely. New
> clients should check with introducer if a NURL (HTTP) has replaced a FURL
> (Foolscap) and update appropriately.
> 6. The client may only have FURL, and not have introducer. For that
> situation the Foolscap protocol should grow a away for clients to get new
> URLs.

New description:

 Each of these will be zero or more additional tickets:

 1. Storage nodes can be started with HTTP protocol (It is maybe possible
 but not worth doing to do this via storage plugin.)
 2. Storage nodes send the NURL to an introducer, in addition to the fURL
 for legacy Foolscap protocol. This is sent as an announcement upgrade so
 it supercedes existing announcement.
 3. The introducer sends NURLs to storage clients. INVARIANT: old storage
 clients can safely get and ignore NURLs. If this is not the case, some
 conditional logic needs to be introduced so old clients don't get NURLs.
 4. The storage client understands NURLs, and use HTTP protocol instead of
 Foolscap when possible. See design doc for further discussion (QUESTION:
 is it actually possible to say "this furl and nurl are for the same
 server"? technically, maybe but not necessary given announcement
 upgrades).
 5. Currently the storage client caches per-server FURLs indefinitely. New
 clients should check with introducer if a NURL (HTTP) has replaced a FURL
 (Foolscap) and update appropriately.
 6. The client may only have FURL, and not have introducer. For that
 situation the Foolscap protocol should grow a away for clients to get new
 URLs (`remote_get_version`?)

--

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