| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| | |
rpc: Document what is actually going on with stream optimism.
Closes #1583
See merge request tpo/core/arti!2753
|
| | |
| |
| |
| |
| |
| |
| |
| | |
In brief: we _do_ correct implement correct optimistic vs
nonoptimistic behavior for RPC streams. Only our documentation was
wrong. Subsequent commits will fix our documentation more.
See #1583.
|
| | |
| |
| |
| |
| | |
Since these return a client-specific type,
they need a client-specific name before we can stabilize them for RPC.
|
| | |
| |
| |
| |
| |
| | |
The API for this type, and the fact that it implements
ClientStreamCtrl unconditionally, means that it is only for client
DataStreams.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
| |
This method doesn't actually create a new stream; it creates a
single-use client object that can be used with SOCKS to launch
a new stream, and capture an RPC object for that stream.
Closes #1664.
|
| |
|
|
|
|
|
|
|
| |
I'm about to remove HasKind from InvokeError, which would otherwise
break this code.
These errors are all in fact internal errors, since in this context
they can only stem from incorrectly formed calls to
`invoke_special_method`.
|
| |
|
|
|
|
| |
Previous documentation was more-or-less meant for the Arti developer
only. This new documentation is intended for actual users of RPC
functionality. It's meant to be extracted with `maint/rpc-doc-tool`.
|
| |
|
|
|
|
|
|
|
|
| |
Calling it "singleton" might have suggested that it was using the
[singleton pattern](https://en.wikipedia.org/wiki/Singleton_pattern),
which it isn't.
(Renaming done with rust-analyzer and double-checked with `git grep`.)
Closes #1585.
|
| | |
|
| |
|
|
|
| |
It is no longer necessary to say, for every RPC method,
that its error type is RpcError.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On its own, this might not seem like a huge improvement, but it will
later let us implement these RPC methods for types that can't
reasonably implement ClientConnectionTarget.
It also serves as a proof of concept that special-method invocation
can actually work, so that we can build things like this in cases
where introducing a trait isn't practical.
Closes #1427
|
| |
|
|
|
|
|
|
| |
Formerly we used a Box. That was okay at first, but now that we
want RPC methods to be able to invoke other RPC methods, we don't
want the Invocable methods to have to consume the Context.
This requires that Context become Sync.
|
| |
|
|
|
|
|
|
| |
This is needed so that we can cast special methods' return types
properly.
I wish I could make this optional, but Rust doesn't allow
defaulting an associated type.
|
| |
|
|
|
| |
Specifically, we want a single colon, and we want our
method names to be in snake_case.
|
| | |
|
| | |
|
| |
|
|
| |
Also, improve documentation.
|
|
|
The application creates these, using a new-stream-handle RPC command,
on an object that can actually create streams.
Then later, the application provides the (global) identity of one of
these objects when it's making a SOCKS connection. This causes the
object to take hold of a `DataStreamCtrl`.
|
