These changes influence behavior, but not effect compatibility.
(If I messed up, and any crate except for `arti` has non-breaking
API changes, that's still fine, since they are all version
0.x.)
This warning kind of snuck up on us! (See #748) For now, let's
disable it. (I've cleaned it up in a couple of examples, since
those are meant to be more idiomatic and user-facing.)
Closes#748.
This is based on logs that I added locally while I was trying to
debug some startup issues. Hopefully they'll make things easier the
next time there's something to debug.
Part of #677.
This fleshes out the PtReactor that was previously a stub, making it
actually do reactor-ey things. Note that this is entirely untested, and
might not work at all. Hopefully it does, though.
This makes a `pt_state` directory inside .local/share/arti (or the
local equivalent), right next to our existing `state` dir.
Ideally we would use a separate directory for each PT, but we have a
very fuzzy "what is a specific PT" notion.
Closes#667
I prefer that it not take `&mut self`, since PtMgr already has
interior mutability.
I also need it to take `tor_config::Reconfigure` argument, in case
it gains any more smarts about validation in the future.
These are implementation details and we don't want to mark them as
stable.
To do this, I needed to apply some additional options to the example
code's configuration in Cargo.toml.
This commit implements `PtMgr`, a pluggable transport manager
responsible for keeping track of spawned PTs and spawning them to
satisfy client requests on demand.
It does this in two parts: the `PtMgr` type exported to the rest of the
code, and the background `PtReactor` that actually does the spawning;
this design ensures that only one attempt to spawn a PT is active at a
time, and will prove useful later for implementing e.g. timeouts.
A few changes were necessary to the rest of the code in order to make
this all work out. Namely:
- `TransportRegistry`'s API didn't make any sense for two reasons:
- It wasn't feasible for implementors to implement `ChannelFactory`,
since that'd require constructing a `ChanBuilder` (which requires a
bootstrap reporting event sender).
- Treating the PT manager as a registry is over-general; it's only
necessary for it to spawn pluggable transports, so saddling it with
other concerns didn't make any sense.
- (It's possible to get extensibility for arbitrary user customization
by just letting the user swap in a new `ChannelFactory`, anyway.)
- Therefore, the `PtMgr` implements the new `AbstractPtMgr` trait, which
is far more narrowly focused; this only exists to solve a dependency
loop, and is documented as such.
- This provides a `TransportHelper` instead of a `ChannelFactory`.
It doesn't make much sense to have the pluggable transport manager be a
registry, so replace its interface with a more narrowly defined, less generic
version.
Other changes:
- instead of returning a &-reference, it returns an owned Arc, which
should make the ptmgr easier to implement while allowing efficient
reuse
- provision for error handling is added, but will probably be revised in
a future commit pending discussion
- tor-ptmgr code that would generate warnings as a result of this change
is temporarily removed
This is a split out version of arti!886, intended so work on arti#659
can proceed.
This brings the draft configuration mechanisms in tor-ptmgr in line with
the config in other crates, using builders. It also plumbs the config
type through into the main `arti-client` config, and adds some example
lines to `arti-example-config.toml`.