Group Details Private

administrators

Forum Administrators

Member List

  • We're moving ... to Discord

    Unfortunately, maintaining a community forum such as this one is a lot of work. Work that currently keeps me from working on Server State.

    This is why we’re moving to a Discord community, which is much easier for us to manage.

    Please join our Discord community at https://discord.gg/NrT9HMCJgt. I’m looking forward to seeing you there!

    posted in Announcements
  • Plans for the coming weeks

    Hey everyone!

    @fussel178 and I just talked and we’re planning on releasing our re-imagined server-side components in the coming weeks (since we have a university break in the following weeks).

    We probably won’t be able to do a lot when it comes to the client, but we at least want to get the server (with a full GraphQL API and plugin system) out of the way so that if you want to build your own clients, you can already use it.

    Have a great week 🙂 !

    posted in Announcements
  • New homepage

    Server State now has a new website, which we’ll continue to work on (and add more information to) in the near future.

    You can find the new site at https://www.server-state.tech.

    It replaces the following sites, which will soon be unavailable:

    • specs.server-state.tech
    • branding.server-state.tech
    posted in Announcements
  • Server State Re-imagined

    Watch the “Server State Re-imagined” video

    We have decided to re-initiate our efforts within the Server State ecosystem and now base it upon some more standardized technologies. We’ll go into more details in the future, but for now, you can take a look at the video linked above to get a general idea of what we’re up to 😉

    posted in Announcements
  • Proposal: A "universal" Data Format
    Author Pablo Klaschka (@pklaschka)
    Version Rev. 0 (original version)
    Date 2020-07-25
    Est. time for implementation 2 weeks

    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).

    Requirements

    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 data property.

    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 😉)

    Tooling Requirements

    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.

    Final thoughts

    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

    1. is compatible with the current specifications
    2. (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)
    3. To some extend, solves this discrepancy between SMs and FEMs by encouraging a cross-platform-compatible standard, when possible
    posted in RFCs
  • Hi, I'm Pablo. A co-founder of Server State

    Hi, everyone 👋!

    My name’s Pablo Klaschka and I’m a co-founder of Server State and the first chairman of fliegwerk, the organization that develops Server State.

    I’m especially invested into the extensibility and ecosystem aspects of SerSta and am looking forward to working with all of you 🙂 .

    posted in Introductions
  • Frontend UI Framework: IBM Carbon UI

    Propsosal to use the IBM Carbon UI system (including their React implementation) for the web client and as recommended and provided UI framework for the FEMs.

    Links

    https://www.carbondesignsystem.com/

    posted in RFCs
  • RE: Frontend UI Framework: react-md

    Positive

    • Theming via SCSS (no CSS in JS)
    • Customizable Material Design
    • Intuitive Component usage (<Button> behaves similarly/the same as <button>)
    • Accessible
    • relatively lightweight
    • Low-Level-Components => high level of customizability

    Negative

    • Low-Level-Components => Layout has to get done manually
    • no IE11-Support
    • Relatively slow development cycle (only one primary developer/maintainer)
    posted in RFCs
  • Frontend UI Framework: react-md

    Propsosal to use the react-md v2 framework for the web client and as recommended and provided UI framework for the FEMs.

    Links

    posted in RFCs