That’s helpful to know at a high level. One thing you’ll want to decide on in the Rust version is ownership over the
Proxy objects. Who will keep the
Connection alive? Is the connection going to be shared across callers on a single thread? Will it be shared across threads? Will
Connection require a
&mut self to perform anything? Do you want multiple
Proxy instances for a single hub to be handed out at the same time (or allow that facility)? Or should there only be 1
Proxy outstanding (i.e. client having a handle to it) for a given hub?
These types of things are usually not a consideration in C# but you’ll want to think about this part for Rust. This will dictate how you design your API.
At first blush, the closest thing to a C# version (without the asynchronous/multithreaded parts for now) would probably be
Proxy objects that internally have some shareable (in the
Arc sense) parts. A client requests a new proxy via
create, and this either returns a
clone() of an existing one (if it’s already in the map) or inserts a clone into the map and returns another clone (again, in the
Rc sense) to the caller. To hide the refcounting, you’d keep these inner shareable components private to your crate; the publicly visible
Proxy would just be shims over these internal parts.
The above may not be the best, but I envision something like that being the closest to what you probably have in C#, although I’m just speculating. You can also consider foregoing the
Proxy object and just allowing calling hub methods on the
Connection itself (or whatever you name that type).
At any rate, you’ll want to think extra carefully about ownership and relationships (who owns what? how is it borrowed? etc) in the Rust version.