Changes between Initial Version and Version 1 of Ticket #203, comment 27


Ignore:
Timestamp:
10/30/2013 09:53:37 PM (10 years ago)
Author:
str4d
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #203, comment 27

    initial v1  
    1010That `decode_location_hints()` returns the host and port as a tuple is symptomatic of the larger rewrite that is necessary to move to endpoints. Many wires do have a host/port concept (TCP, UDP, I2P, Tor), but others may not (Unix sockets).
    1111
    12 A FURL contains the required hints for a client to find a server. I think that should directly translate to the required arguments for the client endpoints. Instead of storing `(type, host port)` for each hint, I propose that either `locationHint`, `(type, locationHint)` or `(type, reqParams)` is stored (where `reqParams` is `locationHint` with `type:` stripped from the front).
     12A FURL contains the required hints for a client to find a server. I think that should directly translate to the required arguments for the client endpoints. Instead of storing `(type, host, port)` for each hint, I propose that either `locationHint`, `(type, locationHint)` or `(type, reqParams)` is stored (where `reqParams` is `locationHint` with `type:` stripped from the front).
    1313
    1414The location hints are eventually used in `foolscap.negotiate.TubConnector.connectToAll()`, which pops a `(host, port)` pair and calls `reactor.connectTCP()` on that pair. This is where `clientFromString()` would instead be used, based on a generated client endpoint description string: