||Pablo Klaschka (@pklaschka)
||Rev. 0 (original version)
|Est. time for implementation
This RFC is a proposal for a “universal” DF that could get used by specialized SMs that don’t want to distribute a specialized FEM additionally.
The primary goal would be to create a data format that, on a high level, describes the data it contains (which can contain several datasets in multiple other data formats).
We don’t want to do this on a low-level, describing the actual layout of the visualization (i.e., basically, generating the necessary HTML code). The aim is to create a data structure that simply describes what its content describes and leaves it up to the interpreting FEM to display it in a manner that’s suitable for the device that presents that data).
The Data Format must support:
- definitions of what the data shows (is it a list of CPUs or hard drives?)
- common high-level information structures (lists, tables, key-value-pair-data, numbers with units, etc.)
- hierarchical data (a table-like data set could contain, in one of its fields, a list; this might get visualized in a popup when an Expand button in that cell gets clicked)
- two or more datasets that belong to the same hierarchical “position” but are, in some sense, independent. A possible visualization might be tabs for the different datasets.
How it could look like
type: 'universal', // indicate to clients that this is a universal DF dataset
data: [...] // the data itself
Each dataset is represented by an
object. On its own root level, defines its type (based on a pre-defined set of types like parallel, list, or table, cf. the Requirements above) as
type, necessary “Metadata” (the value’s name, unit, …) and its actual data as
Datasets can, in the hierarchical data, can contain other datasets (a table cell a number with a unit, tabs tables, and lists, etc.)
The DF’s root
data field can be of any dataset type (even “just” a string )
Typescript definitions (and possibly implementations) of the data set types would need to exist as a library to make working with such an abstract data format feasible.
A FEM that, at least at some raw level, interprets the data format and visualizes it accordingly would also be required.
The discrepancy between SMs and FEMs is, as of right now, one of the biggest difficulties of the SerSta ecosystem. This RFC proposes adding a concept that
- is compatible with the current specifications
- (because of 1.) keeps the option of individual FEMs when required (and thus, doesn’t take away from the modularity of the Server State system)
- To some extend, solves this discrepancy between SMs and FEMs by encouraging a cross-platform-compatible standard, when possible