[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.
> 2. Storage nodes send the NURL to an introducer, in addition to the fURL
> for legacy Foolscap protocol.
> 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"?).
> 5. Currently the storage client caches per-server FURLs indefinitely. New
> clients should check if a NURL (HTTP) has replaced a FURL (Foolscap) and
> update appropriately.

New description:

 Each of these will be zero or more additional tickets:

 1. Storage nodes can be started with HTTP protocol (QUESTION: is it worth
 doing this via storage plugin?)
 2. Storage nodes send the NURL to an introducer, in addition to the fURL
 for legacy Foolscap protocol.
 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"?).
 5. Currently the storage client caches per-server FURLs indefinitely. New
 clients should check if a NURL (HTTP) has replaced a FURL (Foolscap) and
 update appropriately.

--

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