final design decisions before v1.0 about stremio-core HOT 1 CLOSED

Due to many complicated bits, like the player and detail page, we're most likely elm-ing it.

• we can do update(&mut self, &Ctx) for regular containers
• the Ctx itself will be a container that exposes an update(&mut self, &action)
• the Ctx container may actually become cleaner than the contextM since we'll just make a message Internal::UpdateCtx and eliminate the need for interior mutability
• a #[derive] macro will allow us to compose many types that implement update
• this will compose in nicely with elm-like frameworks (seed-rs) but it will also compose great with React/Conrod/whatever with a bit of glue: create a struct that manages mutability and Ctx; we can also provide glue:
  • something that will return a channel Sender (for actions) and a Receiver (for new states and other outputs, e.g. errors), and will manage context and will consume a struct that implements update
• LibAddon's interior mutability might need to be re-thought too
• we should probably sync the library on log-in; It makes a lot of sense for UX

Example API:

// TODO all those will have to take a type arg for Env....
#[derive(StremioModel)]
pub struct StremioModel {
   pub discover: CatalogFiltered,
   pub board: CatalogGrouped,
   pub player: Player<PlayerImpl>
}

let mut stremio = StremioModel::new();
let ctx = Ctx::new();
stremio.update(&ctx); // will return a Vec of futures that have to be handled

// or more sophisticated
// TODO: figure out a better name for this
let (tx, rx) = App::with_managed_context::<Env>();
// send actions to tx
//rx.for_each() // do something with the new &model

NOTE: the models might have to take AddonTransport besides Env

from stremio-core.