| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| |
|
|
| |
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`.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(These will later become objects that can receive any application
request, once we have HTTP connect.)
For now, Session and TorClient implement this trait;
but soon there will be a new type to hold on to the created
DataStreamCtrl.
There are some XXXXs here, marking code that is too ugly to live.
I should fix it before I merge this branch.
|
| |
|
|
|
|
|
| |
Instead, add a trait so that we can hold TorClient<R> and invoke
only the methods on it that we need.
This is a partial revert of 47f012829d3381fd896c6b6f20961fbfe2f40f6d.
|
| |
|
|
| |
I think I'm going to add another stream management module here.
|
| | |
|
| |
|
|
|
|
| |
This change allows it to hold a TorClient<R> that isn't type-erased.
We'll use this for cases when we need to get the client directly
and call functions on it.
|
| |\
| |
| |
| |
| |
| |
| | |
add_warning/CI: New strategy to avoid "unexpected-cfgs" warning
Closes #1395
See merge request tpo/core/arti!2129
|
| | |
| |
| |
| | |
This commit is automatically generated.
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
| |
These are no longer needed, since they are inferred from the types
of the functions.
|
| | |
|
| |
|
|
|
|
|
|
| |
This will be called _static_ to make it clear that it registers the
method statically, so you don't need to install it at runtime.
After a bit more work, there will be a separate macro that declares
an installer function.
|
| |
|
|
|
|
|
|
|
| |
We don't actually need this to be a trait; we just need
methods and objects to have a `CONST_TYPE_ID_` if they want to
participate in the inventory-based method registry.
Removing this trait makes it much simpler to declare methods and
objects.
|
| |
|
|
|
|
| |
This simplifies our implementation logic in a few places,
and simplifies our invocation syntax greatly. There are a few
infelicities, noted in `TODO RPC` comments.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
These are no longer needed.
|
| |
|
|
| |
Closes #950.
|
| | |
|
| |\
| |
| |
| |
| | |
rpc: Minor docs improvements
See merge request tpo/core/arti!1260
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
| |
This will later let us tell the session-creation function
how the authentication occurred, which will let it decide
what privileges to provide.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Formerly, every time we wanted to launch a new connection, we had
to give the RpcMgr a TorClient. The connection would hold that
TorClient until a session was authenticated, and then would wrap
it in a Session and put it in the object map.
Now, the RpcMgr holds a Box<dyn Fn()...> that knows how to
create Sessions. When a connection is authenticated, it
asks the Mgr to make it a new session. This lets us make it
clearer that the TorClient simply can't be given out until the
connection is authenticated. Later, it will let us create
more types of Session objects under more complicated rules.
|
| | |
|
| |
|
|
|
| |
We'll want to move the responsibility for creating Sessions outside
the rpcmgr crate.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This adds a Weak reference from Connection to Mgr, makes DispatchTable
mutable, and makes a few other changes as discussed between me and
Diziet the other week.
I bet we are not done tweaking this, but I hope it's a setp forwards.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a rather tricky piece of functionality. It works as
follows.
We introduce a `CastTable` type. Each `CastTable` tells us how to
downcast `dyn Object` for objects of a single concrete type.
The `Object` type now has a `get_casttable` method that returns
an empty `CastTable` by default.
`CastTable` is, internally, a map from the `TypeId` of the target
dyn Trait reference type to a function
`fn(&dyn Object) -> &dyn Trait`. These functions are stored as
`Box<dyn Any + ...>`. (They are Boxed because they may refer to
generic functions, which you can't get a static reference to,
and they're Any because the functions have different types.)
The `decl_object!` macro now implements `get_casttable` as
appropriate. (The syntax is a bit janky, but that's what we get
for not using derive_adhoc.) For non-generic types, `get_casttable`
uses a Lazy<CastTable>`. to initialize a CastTable exactly once.
For generic types, it use a `Lazy<RwLock<HashMap<..>>` to
build one CastTable per instantiation of the generic type.
This could probably be optimized a bit more, the yaks could be
shaved in a more scintillating hairstyle, and the syntax for
generic `decl_object` could definitely be improved.
|
| | |
|
| | |
|
| | |
|