Pull more things from 0.3.2

This commit is contained in:
Nadja Reitzenstein 2022-03-12 01:27:58 +01:00
parent 495f9cb36a
commit f367207d01
4 changed files with 34 additions and 11 deletions

View File

@ -6,6 +6,9 @@ use futures_signals::signal::{MutableSignalRef, ReadOnlyMutable, Signal};
use futures_util::future::BoxFuture;
use crate::resources::state::State;
mod shelly;
pub trait Actor {
fn apply(&mut self, state: State) -> BoxFuture<'static, ()>;
}

View File

@ -1,11 +1,31 @@
use std::sync::Arc;
use rsasl::error::SASLError;
use rsasl::mechname::Mechname;
use rsasl::SASL;
use rsasl::session::Session;
pub mod db;
pub struct AuthenticationHandler {
struct Inner {
rsasl: SASL,
}
impl Inner {
pub fn new(rsasl: SASL) -> Self {
Self { rsasl }
}
}
#[derive(Clone)]
pub struct AuthenticationHandler {
inner: Arc<Inner>,
}
impl AuthenticationHandler {
pub fn new(rsasl: SASL) -> Self {
Self { inner: Arc::new(Inner::new(rsasl)) }
}
pub fn start(&self, mechanism: &Mechname) -> Result<Session, SASLError> {
self.inner.rsasl.server_start(mechanism)
}
}

View File

@ -27,7 +27,7 @@ impl AuthenticationSystem for Authentication {
}
fn abort(&mut self, _: AbortParams, _: AbortResults) -> Promise<(), Error> {
std::mem::replace(&mut self.state, State::Aborted);
self.state = State::Aborted;
Promise::ok(())
}
}

View File

@ -96,14 +96,14 @@ impl ResourceDriver {
match self.res.on_update(&state).await {
Ok(outstate) => {
// FIXME: Send any error here to some global error collector. A failed write to
// the DB is not necessarily fatal, but it means that BFFH is now in an
// inconsistent state until a future update succeeds with writing to the DB.
// Not applying the new state isn't correct either since we don't know what the
// internal logic of the resources has done to make this happen.
// Another half right solution is to unwrap and recreate everything.
// "Best" solution would be to tell the resources to rollback their interal
// changes on a fatal failure and then notify the Claimant, while simply trying
// again for temporary failures.
// the DB is not necessarily fatal, but it means that BFFH is now in an
// inconsistent state until a future update succeeds with writing to the DB.
// Not applying the new state isn't correct either since we don't know what the
// internal logic of the resources has done to make this happen.
// Another half right solution is to unwrap and recreate everything.
// "Best" solution would be to tell the resources to rollback their interal
// changes on a fatal failure and then notify the Claimant, while simply trying
// again for temporary failures.
let _ = self.db.set(&state, &outstate);
self.signal.set(outstate);
},