Begrifflichkeit Keyboard -> Neustrukturierung DoorPi

[motom001]

Keyboard ist der Name von einer Ein- und Ausgabeschnittstelle - egal ob Taster, RFID, ...
Der Name ist historisch gewachsen und bisher drin geblieben. Nun frage ich mich aber mehr und mehr, ob das noch richtig so ist. Eigentlich gibt es DoorPi und den Event-Handler. Alles andere sind Schnittstellen.

Wie seht Ihr das (speziell @Schwa-l-be beim Doku schreiben)?
Die Änderungen wären tiefgreifend und umfassend - aber jetzt noch besser möglich, als in x Monaten.

[motom001]

Vorschläge von mir wäre plugins, interfaces, extensions, ...

[motom001]

Eventuell andere Idee - DoorPi ist das Hirn, EventHandler das Herz, Actions die Füße und alle keyboards sind die Hände...
Die Vorstellung finde ich niedlich :)

[Schwa-l-be]

stimmt schon zu Beginn war der Begriff mehr als perfekt durch die vielen Möglichkeiten jetzt mit WebIF, Software"Keyboard", Hardware"Keyboard" ist das nicht mehr passend. Wenn wir einen guten Begriff finden, bin ich gerne bereit das zu ändern.
Interfaces find ich ganz gut, denke damit können die meisten was anfangen.

[motom001]

Was sagt Ihr zu dieser Struktur:
https://github.com/motom001/DoorPi2

Gedankengang:
Es gibt plugins in DoorPi die einmal actions und einmal interfaces sein können. Was die Actions sind, sollte sowei klar sein

In den Interfaces sind alle aktuellen keyboards, sipphones, webserver und webservice. Egal was davon, es ist ein Interface. Der Vorteil davon ist, dass ich die config sinnvoller aufbauen kann. Die würde sich von dem ini-Design zu einem JSON hin verändern.
https://raw.githubusercontent.com/motom001/DoorPi2/master/config/doorpi.json

Nächster Vorteil, ich kann ein Interface nach dem nächsten laden und um jedes eine try except Anweisung setzen - damit wird DoorPi selbst wesentlich stabiler, speziell für die Erstkonfiguration.
Außerdem kann ich dann einzelne Interfaces später wieder löschen und neu hinzufügen. Das entspricht in etwa dem Neuladen.

Die Schnittstellen dazu würde ich eindeutiger fassen und ggf. auf Fehler laufen lassen, wenn nicht alle oder komische Werte übergeben werden. Da es schon als JSON vorliegt, kann ich es von JSON gleich in eine Python Objekt wandeln lassen und kann somit split etc sparen.

Die Config sollte dann primär über die Weboberfläche erzeugt werden.

Was sagt Ihr dazu? Könnt Ihr das noch verstehen oder ist es zu weit weg vom "Benutzer"?

[motom001]

So - erstes Grundgerüst ist erstellt. Ich bin begeistert, da ich immens viel Altlasten neu ordnen konnte und ein sehr gutes Gefühl bei dem jetzigen Stand habe.