bunnie b7453b627e add API tokens to prediction API ... The prediction API now takes an API token. This is a 128-bit number that gets passed to the prediction engine, and it's meant to be unique for every context that requires a predictor. It's up to the prediction engine to do anything with the token. For the "null" engines (such as the icontray for `vault` and `tts`) the token is just ignored. But for example, in `shellchat`, the API token is used to store a history record in a HashMap on a per-token basis. This means that every app that uses the `shellchat` history function gets their own history that can only be read out by that app. The actual token itself is mostly passed through the API. The token storage is in the Context layer (each Context has a record for a token, that starts as `None`), and is passed down to the predictor every time the context swaps, and the predictor receives the token and passes it back if the token was `Some`, or allocates a new random token if it was `None`. Note that everything is a Context, including, for example, menus and modal dialog boxes, but not all contexts have predictors. Only Contexts that ask for a predictor have them. This mechanism works smoothly in this model (as opposed to other hacks and work-arounds previously tried getting to this solution).		2022-06-19 01:01:25 +08:00
..
src	add API tokens to prediction API	2022-06-19 01:01:25 +08:00
Cargo.toml	fix #174	2022-06-10 21:36:53 +08:00