Standard command interface - get/set general

[martinp876]

Hi again,
mich stört immer wieder einegewisse Unzuverläsigkeit und schlechte Lesbarkeit bei Kommandos und deren Argumenten. Ich sehe hier potential dies zu "harmonisieren" - was (aus meiner Sicht) mehrere positive Nebeneffekte hat.
Grundsätzlich sollten m.E kommandos (set/get)
 - syntatkisch präzise und parsebar definiert werden
 - optionen klar erkennbar sein
 - dynamisch angepasst werden (fällt ein Kommando weg , weil die Knfiguration es nicht mehr her gibt) erscheint es auch nicht mehr - gleiches gilt für argumente und deren optionen
  - parsen muss schnell gehen - insbesondere die Antwort auf "?" welche im webinterface ständig benutzt wird
  - default werte müssen definiert werden und sichtbar sein.
  - die Syntax muss in eine Zeile passen (prosa im commandref) - kleine Kommentare möglich

So konnte die Definition einesKommando aussehen
#dimmer schalten - sektion "set"
dim 'level' 0..100;0.5,on,off 'ontime' [0..100000,{forefer}] 'rampUp' [0..100000,{2}]
#allgemein:
connect device1|device2|device3
#allgemein:
setCmd opt1|opt2|-setOptions-

=> in meinen Beuspielcode sind kommandos zum Testen aufgeführt

Was ist nun der added value
Für den Anwender:
  - ein "get cmdList" muss angeboten werden. Hier kann man übersichtlich alle kommandos sehen
  - optionale Argumente werden erkannt - defaults gelistet
  - aller Optionen sind aktuell. Sollte eine Entity umdefiniert werden (schalter zu dimmer, Datenbank ist noch toracle sondern sql,...) - ich sehe immer nur meine gütigen kommandos
  - generische Kommandos lassen sich integrieren (list für Entity)
  - sichtbarkeit des module-levels
  - geschwindigkeit insbesonderen bei umfangreichen Kommandolisten
  - support des default WEBinterface (noArg/multiple/...)
 
Für den Entwickler
  - der Parser prüft die Kommandos auf einhalten der Regeln:
     + Anzahl der Argumentet
     + bereitstellen der defaults
  - Behandlung des WEBinterface
  - vereinheitlichung der Verarbeitung

Es bleiben dem Entwickler alle möglichkeinte offen, kommandos flexibel zu ertellen
Performance ist immer Prio 1 - wobei die Verarbeitungszeit zur Laufzeit hier zuerst kommt.

Kommandos werden auf Modul-ebene oder auf Entity-ebenen ertellt - je nach Anwendung. Beides kann gemischt werden
Globale Kommandos werden natürlich auch bearbeitet.

Optionen werden komplett eingepflegt. Wenn also partner-device zur Auswahl stehen wird dies schon im Kommando abgefangen.

Ich habe dies als Modul erstellt - eigentlich sollte dies im Kern verankert werden. Das sieht dann leicht anders aus die Einbindung wird etwas einfacher.
Sind die Kommandos erst einma definiert muss der Entwickler fast nichts mehr machen. Nur den Parser aufrufen.
Auch die Rejections zu den Aufrufen werden gleich erledigt. Standartisiert

Ich sehe dies(es Herangehen) als klaren Schritt nach vorne. Es zwingt zu etwas stringenz an einer Stelle an welcher nicht wirklich Freiraum gebraucht wird.

Bei mir funktioniert es und ich baue es in alle gekaperten Module ein, welche ich meine anpassen zu mussen. Es erleichtert am Ende die Arbeit als Entwickler und als User


Der Code enthält ein paar weitere Erweiterungen - so z.b. einen Beziehungs-analysator. Der ist natürlich optional - gehör nicht zum Kern.

Das Modul ist einfach einzubnden - zum Versuchtn. Die Kommandos "get" sind zum Spielen und üben.
=> das modul wir so nie (von mir) veröffentlicht werden. Es wird im kernal eingebaut und von dort verwaltet (angepasst) oder eben nicht.

Im COde sind einige Kommentar...