SystemQuery: layout some stuff, but it's really just scaffolding at the moment.

We've not even sure if this is the right way t go about tackling this 
problem.
This commit is contained in:
Starbeamrainbowlabs 2022-01-31 03:06:34 +00:00
parent 9ac878f261
commit 15bdcaf047
Signed by: sbrl
GPG key ID: 1BE5172E637709C2

View file

@ -5,7 +5,10 @@ import Agent from './agent/Agent.mjs';
import InfoBroker from './core/InfoBroker.mjs';
class SystemQuery {
constructor(config) {
constructor(config, mode = "agent") {
// The operating mode. Possible values: agent [default], query_client
// TODO: Is this the best way of doing this? Maybe we should have a separate class for this? I'm not sure.
this.mode = mode;
this.config = config;
this.info = new InfoBroker();
}
@ -39,6 +42,25 @@ class SystemQuery {
async handle_query_response(peer, msg) {
}
async fetch_table(name) {
// If it isn't valid for us, it ain't gonna be valid for anyone else....
if(!this.info.is_valid_table(name)) return null;
const responses = {}; // peer id → table
const handle_response = async (peer, msg) => {
// TODO: Validate response. Is it the right table? Is it even a table? Note that multiple fetch_table calls may be running in parallel, so we should not make too much of a fuss if we get the wrong table by accident.
// TODO: It would be seriously cool to have fetch_table() be an async generator that yields pairs of peer ids and tables as they come in.
if(no_peers_left_or_hit_timeout) {
this.off("message-query-response", handle_response);
}
};
this.on("message-query-response", handle_response);
// FUTURE: Add a cache here? Note that we also do not listen for query responses unless we've asked for a table.
}
}
SystemQuery.Create = async function(config) {