Open rrichardson opened 4 years ago
Ah, that's an interesting to this. I'm a little worried about constructing a LocalAuthority
this way, since it's not intended to be used in this fashion. Its impl Authority
assumes that everyone shares the same LocalAuthority
instance. In this particular case, it doesn't matter too much, since the client doesn't actually use the Authority
part for anything except "discovering" the leader, but it's definitely an abuse of the API that might bite us later. I wonder whether a better approach here would be to write a new type, DirectClientAuthority
, which implements Authority
but is constructed by giving a controller address, yields that address when asked, and apart from that returns panic!("DirectClientAuthority can only be used by Noria clients, not by workers")
.
@jonhoo - I agree that using LocalAuthority
in this way is an abuse. It was suggested in the ticket that there be a ConfigAuthority
which makes a bit of sense.. it would be a read-only authority.
What about breaking the Authority
trait into two traits:
So the ZookeeperAuthority struct would actually implement both, but the ConfigAuthority would only implement the read portion (being directly initialized with a Map of some sort )
Sure, that seems like a reasonable way to do it. Maybe Discover
(for finding the controller) and Participate
(for becoming a worker)?
This is a proposal for how to manage configuring a client with the static address of a server. It builds, but I haven't tested it. I want to make sure this is a sane approach before I go further.
I had to create a
run()
function so that I could statically dispatch based on the type ofAuthority
. I was unable to BoxSyncControllerHandle
without editing the noria code.