Direkt zum Hauptinhalt

FabAccess - Versionen, Changelog, Roadmap

Roadmap

Server

Client

Weitere Anfragen / Community Feature Requests

  • SRV Record Unterstützung für Clients
  • Maschinen nach einer Inaktivitätszeit X automatisch ausschalten (Aktivitätsmessung, Verbrauchsmessung?)
    • BFFH soll über sog. "Sensoren" Informationen über die Welt rausfinden. Das werden so wie Aktoren & Initiatoren modulare Stücke Code oder sogar externe Skripte sein, die relativ unabhängig vom restlichen Code sind. Gemanagte Ressourcen (aka "Maschinen") können dann via der Config "Module" definieren, die ihr Verhalten verändern können. Eines dieser Module nimmt Daten aus so einem Sensor und gibt eine Ressource wieder frei wenn sie augenscheinlich nicht mehr verwendet wird.
    • Implementierung der Aktivitätsmessung ist noch nicht ganz klar, aber der Modularität halber wird es sehr wahrscheinlich so aussehen, dass genau das nur im Sensor passiert und der Sensor nur mehr einen Output von "wird gerade verwendet" oder "wird nicht verwendet" hat. Wie genau der Sensor das errät, ist dann das nächste Problem, aber jetzt im Bezug auf das vorhandene Skript hieße das dann mehr oder weniger nur, dass das anstatt von direkt auf den MQTT-Bus zu schreiben in BFFH reinschreibt.
  • App und/oder Server: Pet Names / nutzerfreundliche Namen: sich keine Nick Names merken müssen ((z.B. in einer zweiten Zeile unter dem Username). Wenn man z.B. Mitgliedschaftsnummern als Login verwendet, dann ist die User-Liste in der App nicht wirklich gut nutzbar, weil man zusätzlich eine Liste mit den Account-Zuordnungen benötigt.
  • Meta-Daten für Maschinen und Nutzer ergänzen, z.B. Adressen, Mitgliedsnummer, Avatar, Beschreibungen, etc. - könnten dann z.B. in Abrechnungssystem gegeben werden, im Audit Log auftauchen oder einfach nur in der App bessere Details anzeigen

  • Zugangsdaten für Mitglieder als QR-Code einscannen. Hintergrund: Zur Identifikation mit civiCRM verwenden wir eine vierstellige UserID, die sich keiner merkt. Um das "Problemchen" zu umgehen wäre es nett die initialen Anmeldedaten innerhalb eines QR-Codes / Links einscannen zu können 

  • Login mit FIDO2 / Passkeys / YubiKey?
  • Login mit SmartCard via ReinerSCT Card Reader?
  • Internationalisierung
    • Client auf Deutsch
  • Wie installiert man FabAccess betriebssicher? (Fail-Over Strategien, Backup-Strategien). Was machen, wenn der FabAccess Server down ist?
    • Zweit-Server mit Spiegelung der Datenbank?
    • High-Availability Cluster (Kubernetes?)
    • Unterbrechungsfreie Stromversorgung (USV)?
    • Funkunterbrechungen / schlechte Signalstärken (da, wo es möglich ist, ein Ethernetkabel ziehen)
  • Wie/mit welchem Tool lassen sich Maschineneinweisungen sinnvoll tracken/ins System einbinden?

Release History

Bei den folgend genannten Versionen wird primär von der API-Version gesprochen! Die Versionen des Servers und des Referenz-Clients können sich unterschieden. Clients in den App Stores müssen der Server-Version entsprechen, bis die Version 1.0 erreicht ist!

  • ☑️ 0.4 Beta (aktuell)
  • ☑️ 0.3 öffentliche Alpha "Spigots of Berlin" (04/2022)
  • ☑️ 0.2 Joris-Alpha (01/2022)
  • ☑️ 0.1 historische Alpha-Version

Siehe auch Stichwort release.

Alle Releases von Borepin und Diflouroborane (BFFH) finden sich in GitLab:

Release- und Versionierungsschema

Wie werden die FabAccess Repositories versioniert? Welchen Regeln folgt es?

Das Versionsschema lautet A.B.C. Wofür die 3 Stellen A, B und C stehen, ist leider nirgends erläutert.

Folgende Release-Stages gibt es:

  • Internal - nur für interner Tests
  • Beta - für externe Tester
  • Production - für alle Nutzer
Keine Kommentare
nach oben