mirrors/arti.git/crates/tor-rpcbase/src/dispatch.rs, branch arti-1.2.1

Run maint/add_warning.

2024-03-13T16:30:53Z

Run maint/add_warning to add lint block everywhere

2023-08-23T09:34:00Z

Run maint/add_warning to actually apply new lint allows

2023-07-10T12:49:51Z

rpc: Cross-reference up from tor-rpcbase re where DispatchTable lives

2023-06-16T16:48:59Z

RPC: Functionality to downcast dyn Object to a dyn Trait.

2023-06-12T17:35:28Z

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`. (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`. to initialize a CastTable exactly once. For generic types, it use a `Lazy>` 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.

rpc: make decl_object! responsible for writing impl Object {} blocks.

2023-06-07T18:37:04Z

rpc: Remove downgrade_owned for now

2023-05-24T14:15:56Z

Rationale: Our weak-vs-strong design is a bit confused at the moment due to concerns about deduplication and capability semantics. It's not clear that a general "change strong to weak" method is compatible with what we want to provide.

rpc: Implement functionality to remove objects from a session

2023-05-24T14:15:56Z

I've made doing some design choices here: * Reserving "rpc" as a prefix for post-authentication functionality that is not arti-specific. * Declaring these to be methods on the session rather than methods on the objects themselves. There's a problem with defining an API to drop a weak reference; see comment in code.

RPC: Add "register" methods to RequestContext.

2023-05-04T14:35:05Z

rpc: New syntax for method declaration

2023-04-19T16:38:26Z

Now you just declare your function `my_func` with the right types, and invoke `rpc_invoke_fn!{ my_func(ObjType, MethodType); }`