You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, calling State::handle() with a Proposal validates the proposal and adds it to a queue internal to the State object. This is problematic for a couple of reasons. It means that the State object has to be mutable. And it reduces the application's control over what proposals are committed, since the application can't remove a proposal once it has been enqueued.
A better approach would be to have the application be in charge of managing the proposal queue directly, with State providing the tools to (1) validate proposals before caching and (2) commit a list of proposals.
We have actually already started down this path. #412 provides State::unwrap() to validate a proposal without enqueuing it, and a variant of State::handle() to explicitly enqueue a proposal.
The text was updated successfully, but these errors were encountered:
Right now, calling
State::handle()
with a Proposal validates the proposal and adds it to a queue internal to the State object. This is problematic for a couple of reasons. It means that the State object has to be mutable. And it reduces the application's control over what proposals are committed, since the application can't remove a proposal once it has been enqueued.A better approach would be to have the application be in charge of managing the proposal queue directly, with State providing the tools to (1) validate proposals before caching and (2) commit a list of proposals.
We have actually already started down this path. #412 provides
State::unwrap()
to validate a proposal without enqueuing it, and a variant ofState::handle()
to explicitly enqueue a proposal.The text was updated successfully, but these errors were encountered: