Now that I have something simple and functioning, this no longer needs to be
in the auctioneer
The fun work begins now, supporting custom messages known only to the auctioneer
for its needs, but passing those through EventBusClient
I originally tossed this approach since I believed that the awc +
actix-web-actors approach was unnecessarily complex. After experimenting a bit
with tungstenite, I believe that converting its high-level API into something
that I could work with in an asynchronous manner would require too much poking
around with tokio to be worth the effort.
I suppose I'll have to make do with the somewhat mid-level abstraction that
actix-web-actors provides me.
I think I am going to have to abandon this approach for a couple of different
reasons:
* Bastion does not yet support dynamic supervision
<https://github.com/bastion-rs/bastion/issues/9>
This means that any workers which might handle websocket or other connections
cannot possibly scale because the server would need to start with a fixed number
of children under supervision. Contrary to what we have with actix-web where
we use an actor per connection.
* Tide/tungstenite do not yet integrate. It seems that actix-web and _maybe_
gotham are the only two web frameworks which properly upgrade HTTP
connections to websockets without requiring two fundamentally different servers
to be running.
This makes the auctioneer resilient to total failures on connecting to the
eventbus, but unfortunately spins in a tight loop if the eventbus is offline.
This is just to checkpoint this work. I think I'll be refactoring the eventbus
quite a bit to make sure that each eventbus client doesn't need to do too much
custom actix work
R Tyler Croy